Modeling helps improve the success of delivering a high-quality solution
A primary responsibility of a Solution Architect is the integrity of a given project’s software solution. There are many aspects to a solution’s integrity such as System Quality as well as Traceability to ensure the software actually meets the business needs. There is another that is the topic of this blog post and is a Solution Model. Of course, a model by itself won’t guarantee a high quality solution or traceability. However, if done right, it could and it could help you get there faster.
Keep it simple – Use modeling to describe the problem, the solution and how they relate
Let’s sync on the term Solution Model. It's actually quite simple. I’m referring to the concepts or artifacts a project team manage that:
Getting modeling adopted is hard
Project team members naturally think myopically and avoid contemplating the needs of other team members or groups that depend on their information. Because modeling a Solution Model requires tying all the concepts together across the project team, you can imagine the many challenges to get it adopted by the project team. For example, here are few challenges a project team might face during efforts of gaining adoption:
It’s not about modeling philosophy – focus on the aspects of modeling that bring value to the team
This blog post is not a stroll down theory lane. Although theoretical Modeling concepts, scientific modeling philosophy or modeling methods and paradigms such as MDA, MDD, UML and DSM are interesting, they are about how to model. That is, modeling methods, modeling diagrams and modeling notation. Instead, this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption. Because, in the end, without adoption theory is pointless in our efforts to improve system quality and optimize the business investment.
Sidebar: A Model is not the same as a Diagram. There always seems to be a bit of confusion around this, so I thought I’d make this note. A diagram is merely a View or picture. A Model ensures that the model elements on a diagram have specific meaning in both what they represent and how they relate to other model elements. There could be diagrams of a model but if the diagram doesn't have an underlying model to ensure integrity of the model elements, it is only a picture. Although a diagram is useful, it can be misleading because it is probably inaccurate and only represents a point in time.
Models provide tons of value – the trick is describing it to the project team
So, what's the value of the solution model? Below is a list of value statements to try and answer that question and is the main purpose of this blog post.
You might be wondering about where Project Documents fit into this story. A Project Document, in my opinion, is nothing more than an artifact created for sign-off. I don't think that there are Project Documents that must be created for every project. Identifying which Project Documents to create and their purpose is a decision by the project team directly. There is no hard rule which to use for all projects. Now, what goes in them, I care deeply about. The content of any Project Document should reflect that model. Therefore, a Project Document composes model elements via Views that are designed for a specific set of Stakeholders and their Concerns. Ideally, Project Documents are built/populated from the Solution Model to ensure that the content is accurate.
Here's a simple diagram illustrating how Model Elements, in this case a Requirement, Use Case and Process Activity related to a Project Document using UML notation.
In Summary – a Solution Model is highly valuable. It is worth the effort to get it adopted by the project team.
I covered a lot of ground in this blog post and am talking about an area of modeling not well addressed in the industry. There is tons of information about modeling but little to no information about the business value of modeling nor how to get it adopted by a project team to help a Solution Architect be successful ensuring that a high-quality solution with integrity is delivered. Remember, there are lots of challenges to get a Solution Model adopted. But I hope that through the list of value statements, you will be able to convince your audience to adopt the Solution Model.
A great post by Gabriel: Valuing the Undervalued Solution Model
We all agree now that Adoption is key for Enterprise Architects . And the trick to adoption is resonating
It is nice to point out, on occasion, when two different leaders in the architecture community are saying