System and Software Design Doesn't Need To Be Difficult

By Tim Ackroyd on

For decades, I have worked with many Architects whom are not "Developers". Many say they started as a Developer, yet this doesn't seem to be reflected in their Solution or Application Architecture presented in projects. When I ask why, the answers vary from, "I am out of date with current technologies", to " I'll leave that to the Application Architect or Developers". My response is, "That is too late!".

Often at the start of the effort (e.g., Project), necessary resources are not available. This could be that resources are tide up in other delivery, to the budget doesn't allow for IT. My response to this reasoning is, "You can pay now, or pay considerably more later!".

In the beginning of any effort, and at a minimum, there should be a primary facilitator (e.g., Project Manager), the primary client stakeholder (e.g., Sponsor funding the effort), a primary product or company knowledge source (where knowledge is methods, procedures, basic rules, etc.), and a "Solution" Architect.

  • Facilitator - owns the schedule and the budget
  • Client Stakeholder - owns the purse-strings and liaison to leadership
  • Knowledge Source - Understands the Methods & Procedures (M&P), including Business Rules and Regulations (high-level)
  • Architect - starting with focus on the Solution

Notice I said "Architect" and not "Engineer"! To understand the difference, read my post "Architect vs Engineer". An architect begins by meeting with the client, understanding their needs, goals, and ideas. Ideally, architects provide the following: 

  • High level Design and overall System Architecture
  • High level of abstraction
  • Strategic Decisions about System architecture
  • While thinking of Code, focus on design, architecture, and ensuring software aligns with business goals and requirements
  • Responsibility of the entire system architecture
  • Collaboration with various stakeholders to ensure alignment and convey vision
  • Long Term Goals and evolution of software over time
  • Established coding standards and best practices for development teams

The "Requirements" are the "What" or "Problem" to be solved, and the Solution Architect addresses "Who" will solve the "What" or "Problem". The "Design" is "How" the what/problem "Will" be solved. Thus, it is best to provide a high-level design (at the least) when solving problems. Otherwise, how are we validating that the client's needs will be met or achieved?

In our channel, UML Operator, we provide visual content to accomplish the objectives of Model-Driven Anything.

Comments

Post a Comment

Popular posts from this blog

Sparx EA and Open Collaboration

By Tim Ackroyd on
I get asked, quite often, "Is there a way to integrate Sparx Enterprise Architect (EA) with other tooling?" My answer is always, "Yes". There are multiple approaches, from very simple to more advanced. I have helped several shops do this over the years, and may do videos on this in the future. Integrating Sparx with Azure DevOps and other Cloud platforms, as well as other Tooling, is very possible and beneficial for managing delivery, such as requirements, problem solving, design, and development... all in a unified way.  The integration can allow companies/shops to seamlessly synchronize between Sparx EA's modeling environment and platforms, such as Azure DevOps'. Remember that one of the biggest benefits of Sparx EA over other modeling platforms, is that Sparx is based on Data-First implementation and supports open integration. Years ago, something call Open Services for Lifecycle Collaboration (OSLC) came out and Sparx was one of the first to embrace it. ...
Read more

BPMN Diagram versus Sequence Diagram

By Tim Ackroyd on
I am getting some great questions in our  UML Operator Channel , as we are publishing  a series on Business Process Modeling Notation (BPMN) . Modelers see the term "Sequence" in BPMN and get a little confused...probably my fault 😏. When using BPMN, just understand the difference between Unified Modeling Language (UML) and BPMN (an extension of UML) and things should fall into place. So now let's talk about BPMN vs UML Sequence Diagrams... BPMN Diagram versus Sequence Diagram BPMN diagrams and sequence diagrams are both types of visual representations used in the field of business process modeling and software engineering, respectively. While they share some similarities, they serve different purposes and focus on different aspects of a system or process. BPMN Diagram: Purpose: BPMN (Business Process Model and Notation) is used for modeling and documenting business processes. It provides a standardized way to r...
Read more

MDA vs MDD

By Tim Ackroyd on
This post kicks of a new series on UML Operator Channel  UML Operator Channel around systems and software delivery, titled "Model-Driven Anything". Subscribe, turn on notifications, follow, and most importantly...Contribute 😎 IMPORTANT NOTE: Never start a software development effort without Requirements!!! or Scope!!! However, sometimes software starts out as a means of developing scope and requirements! So what are we talking about? Model-Driven Architecture (MDA) and Model-Driven Development (MDD) are both approaches within the realm of software development that emphasize the use of models as primary artifacts in the software engineering process. However, they have distinct focuses and methodologies. Here are the key differences between the two: Model-Driven Architecture (MDA) Origin and Standardization: Origin: MDA is a software design approach proposed by the Object Management Group (OMG). Standardization: It is a well-defined framework with standardized guidelines and...
Read more