Mike Walker's Blog

A Fool with a Tool is still a Fool

Today I was asked a series interesting questions in regards to why architects are so insistent on collecting models. He asked with passion, why there was a need to capture information from across the enterprise in a systematic way. Of course it didn’t help that there was the beginnings of an architectural current state analysis and road mapping exercise on my whiteboard and posted on my wall.

This led into a series of very challenging questions posed:

• Why would you build a model/picture of an environment or set of systems when you could just walk down the hall and talk to the person that wrote it?
• Isn’t a model subject to interpretation?
• If the architects in the company are looking at these models and making decisions how can we be sure they are making the right ones based on potential inaccuracy of the models.

After talking for about an hour about this I was able to finally get to the source of all the questions. As a developer, this person felt that architects and technical decision makers in the organization would take these models and make decisions in isolation and potentially abused on false information that would in turn potentially impact the developer in a negative way. Now we are getting somewhere… We have a case of Fear Uncertainty and Doubt or FUD. But, this fear is a common fear, especially if the organization has gone from little to no architecture maturity to the very beginnings of a structured architecture discipline.

So we have some FUD here, is this unfounded? Absolutely not. Believe it or not, sometimes architects over engineer or model an application, solution, platform or an enterprise in a less than optimal way. Sometimes downright inaccurate way. So is it fair to be worried, YES!

So this is where we actually get into why I label the post the way I did. So in the analogy, “A Fool with a Tool, is still a Fool” we have a direct correlation with this scenario.

When we look at the “Tool”, it would be the architectural artifact. This could be an architecture description, a model or a set of data supporting a solution.

The “Fool” or potential fool is either the creator or the end user of the specific artifact. Let’s just say that it is an architect for a moment. The architect who is going to use this tool or architecture model for a very specific set of purposes. One being, to make decisions.

For example, if the architect is going to use this information to make decisions it is the responsibility of that architect to think about the following questions:

• Is this the right model I should be basing by decisions off of?
• How accurate is the information displayed in the model? If unsure, ask someone.
• Understand the following principle “all models are false but some are useful”. Models that are created will sometimes have interpretation of a problem built in. As an architect you need to know how to quickly identify these areas.
• What was the created date?
• Are there tools and mechanisms that keep the information refreshed and thus the model can be trusted better.
• Finally, don’t be afraid to ask a lot questions!

What about these initial questions around the validity of the architectural approach? Has anything changed? Do we change the way we make decisions? No you do not. All of these questions center around information quality and collaboration. These are core tenets of good architecture practices. Models are extremely useful if used properly. However, we always need to be mindful of the fact, garbage in equals garbage out. The architecture model is only useful as the diligence that went into it, the maintenance of the information and that it is verified as valid ongoing.

The focus on the model specifically is actually the wrong center of focus. The center of focus should actually be on the user of that model. Let’s change the scenario and say that the model is actually 100% accurate. However, the architect that uses it isn’t the most seasoned and makes bad decisions off of a very accurate model. Where is the breakdown?

At the end of the day, the best tools still need a qualified operator. That is the essence of the analogy and why it applies so much to this scenario.

So if you are not challenging and following models blindly, yes, you are the fool in the scenario. But if you understand that architecture artifacts are just one tool in the toolbox and those tools need to be sharpened, tuned and even sometimes upgraded you’ll be just fine.

Microsoft Steps Up Architecture Modeling

Sudhanshu Hate from Infosys posted a good overview article on the new architecture modeling capabilities in Visual Studio Team System - Architecture Edition.

However, even though Microsoft steps-up in the architecture modeling capability it still lacks the repository aspects that bring the most value. As an example, each one of the models is still file based stored in a project structure. This isn't conducive to enabling architecture management across an organization. Everything is built in a hierarchy within a project.

One other gap is alignment to architecture modeling standards such as Archimate. I think there is an opportunity for Microsoft to leverage this already developed standard in the same way as they did with UML. Rather what we see now is Microsoft's own definition of what a logical model is.

This is a great first step getting the modeling pieces and kudos to the VSTS Team Architecture folks but I would encourage my friends back in Redmond to align more with the architecture industry standards and build out the a repository to enable systematic reuse and to make application portfolio management a reality.

See below for his post (http://www.infosysblogs.com/microsoft/2009/11/architecture_rules_enforcement.html):

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.