PIM to DSL Further Explained

In the previous episode, "From UML Class to Code," I attempted to expose Platform Independent Modeling (PIM) leading in Design so that we can transform to a Domain Specific Language(s) (DSL).

I also stated that we do not teach "coding" on this channel, but I do not want to confuse or mislead modelers who are focused on Design.

In our next episode, Model-Driven Design (PIM to DSL Part 1), I will further explain so that Design can be accomplished in a manner that is not disruptive to the project or your developers.

With that said, let's preface once again that our focus when doing PIM is "Design". This should be referred to as "High-Level Design" as more "Detailed Design" would be using real software language (or Code).

So with that now said, let's break this episode into two parts: High Level Design and Detailed Design as we move from Model-Driven Design to Model-Driven Code (Development).

High-Level Design

High-Level Design (or HLD) is focused on Requirements (nouns and verbs) where nouns are your actors, attributes, and variables. I would prefer to say "Data". Verbs are your functions, methods, operations, and processes.

In HLD we are using the Requirements to build (design) the deliverables.

Detailed Design

Detailed Design (or DD) is focused on your current Code and Technologies implementation(s). This includes Code (or software) and Hardware (systems, deployment, etc.).

In DD we are using the Code Implementations and Deployment to Design our Development and Delivery Approaches.

When and Why

When I stated in the previous episode that we will let the Developers decide what specific language (technologies) to use, I was referring to Detailed Design and Development. During HLD, I am focused on Solution Architects and Enterprise Architects, operating at a high level of abstraction during the Ideation and Requirements Engineering phases of delivery.

In my world there are different levels of Architects:

• Enterprise Architect
• Business Architect
• Solution Architect
• Application Architect
• Data Architect

I tend to think of "Chief Architects" differently than "Enterprise Architects" in that a Chief Architect focuses on the architectural aspects within a specific domain, while Enterprise Architects take a holistic view of the organization's architecture across multiple domains. Both roles are essential for ensuring that the organization's architecture supports its strategic objectives and drives successful outcomes.

Chief Architects work closely with Application Architects, Data Architects, and Developers, while the Enterprise Architects work closely with Business Stakeholders and Architects (respectively).

The Solution Architect is focused on solving the problems of the Business, Project, and/or Delivery at hand. They are focused on the "Requirements" or "problems to be solved".

When To Do What

When developing "Requirements", the Solution Architect follows the lead of the Enterprise Architect to produce a Solution Approach on "who" does the "what". Once a solution(s) has been formed, the Solution Architect turns to the Application Architects relevant to various domains and reaches an agreement on that solution.

The Solution Architect may translate the requirements (nouns and verbs) into high-level designs, working with Application Architects, in which those HLDs could be transformed into Detailed Designs while working with Developers.

Applying UML

In the Unified Modeling Language (UML), especially using Sparx Enterprise Architect (EA), we can model everything from Requirements to Design and all the project management. And we can do this in a common place for the entire Team while collaborating along the way.

This allows Architects to work with all stakeholders in producing models that can be delivered at any level, from ideation to testing and deployment.