Mike Walker's Blog

Enterprise Architecture Tool Assessments

It’s been a busy couple months for the analysts. Both Forrester and Gartner have built out and refreshed their latest Enterprise Architecture Tool Assessments for 2011.

After reading both of them, they actually complement each other. The Gartner analysis reads more like deep research and analysis but the Forrester report is able to bubble the findings up in an easy way. My personal style is to look at the Forrester report first, to determine what vendors I do and don’t want to look at, then go to the Gartner report for the in depth analysis of that vendor.

See below for an example of the style of analysis:

 

Both of these are great reports just different styles and approaches to the outcomes.

So if you are in the market for a new EA Tool or just want to educate yourself on the tools out there and their capabilities take a look at both of these reports. I think you will find value in both.

EA Tools Assessments

• The Forrester Wave™: Enterprise Architecture Management Suites, Q2 2011.
• Gartner Assessment of Enterprise Architecture Tool Capabilities

 

Technorati Tags: Enterprise Architecture Tools,Enteprise Architecture,Forrester,Gartner

Book Review: Troux Enterprise Architecture Solutions

I recently picked up a copy of Troux Enterprise Architecture Solutions by Richard Reese. I have worked with Troux in a variety of capacities in the past along with stacking them up with the other large Enterprise Architecture Tool vendors. I was naturally interested to see what guidance they have outside of the guidance used to operate and support the actual tool.

I was really surprised by the book as it went in a different direction than I thought it would. I expected the book to be largely about the tool. Using the tool as a lead in to the other Enterprise Architecture topics. This wasn't the case at all but rather the complete opposite. Those aspects were pleasant to see.

I have mixed reactions about the book. Just like with everything there are he good and bad aspects. Below are those aspects that I was able to distill out of the book.

The Good

• Practical Models - I really like when authors use real world examples. Obviously there are limitations to this from an IP perspective, however to show how these abstract concepts in  relatable scenarios that the reader would run across is extremely important.
• Right level of Theory and Practice - The book isn't too abstract as EA can get sometimes. There is a theme of practicality to the book.
• Visualizations - the chapter on visualizations was really drove the point home. It gave the reader a view into the tangible capabilities of Troux. There should be more of this in the book. My only negative here is that I wish the author would of gone into more details on the methods and processes that support these visuals. My fear would be that people would use these out of context. It would of been good to have more chapters like this one with rich visuals.
• TOGAF Alignment - Overall this chapter was good as well it provided a good overview and touched how Troux addressed TOGAF. I would however would of liked to see on a feature to process alignment matrix to show how much coverage Troux had on the tool.

The Bad

• Message and Purpose Diluted - I know this may seem fairly harsh, but I found the book to jump around quite a bit. There was a real flow issue with the book content. An example of this is Chapter 5 where organizational models are gone into depth while other chapters such as Metadata, business values or business alignment are either briefly covered or partially covered. After I read the book I wasn't able to takeaway a key message or theme that the author was trying to drive. This led to more questions than answers. That may of been the intent but it would of been setup for the expectation early in the book as I didn't walk away with "Troux Enterprise Architecture Solutions".
• High Level - This contradicts a positive point, I know, but the book was detailed in some areas and extremely vague in others. I think this is what really hurts the book.
• Transformation Platform Architecture - I was really surprised by this chapter. I was expecting more on how to make a platform like Troux scalable functionally along with key patterns to enabling Troux as the EA Knowledge Management tool. However, this chapter doesn't use the same principles that are described to model architectures and doesn't illustrate the architecture of the Troux solution very well. It would be good to see the same models and methods used for LOB applications used to decompose Troux platform to drive the message home.
• Metadata Management - This chapter went from theory directly into technical configuration really fast. While I really liked the trade-offs between centralized vs. decentralized repositories, I was expecting more tangible examples for the readers on the value and uses of metadata management, architecture Ontologies and Taxonomy and the impacts of social computing on how metadata can be enriched. This could of led to a great set of visuals, use cases, examples of kinds of metadata, formats, key lessons learned and how Troux could make metadata much more manageable and ultimately much more usable.
• Business Alignment - This chapter was all over the place. There was only one example of alignment and it was from a relatively unknown company. If there was a few companies that could be used as the basis for the methods it would of made this chapter so much better. However without real statistics, business process improvement or value realization metrics this chapter didn't convince me as a reader.
• Governance - This chapter only focused on standards and the tool. There was no mention of process or people. This is only a very, very small aspect of governance. The organizational structures while fictitious, is a bit misleading as most organizations have a variety of different structures. Finally there was no mention of organizational readiness or maturity that will ultimately drive the activities in which architects establish.
• Generating Business Value - This chapter was all over the place and was extremely high level. Not a whole lot of value gotten. I found most of the techniques mentioned were out of date with the industry. I was surprised by the RAD comments as this term is really outdated. Agile methods have surpassed RAD and have tangibly demonstrated its value. Why Agile methods are not mentioned was concerning as this is the world today not waterfall or RAD. I expected that to be addressed along with how it fits into EA or Troux.

In summary, the book was a bit of a let down for experienced Enterprise Architects but could be useful as a primer of EA's getting into the role that their company uses Troux. Even in that case this book should be supplemented with another set of resources to balance out the details.

Regardless, check out the book for yourself as there is a wealth of visuals that can stimulate you to think about how to make better IT decisions and to better position the value of EA.

MEGA annonces TOGAF and Business Architecture Offerings

Over the past few weeks MEGA an enterprise architecture (EA) tools provider, has recently announced  MEGA for the TOGAF framework and Business architecture solutions. I wanted to raise awareness of this update as a news item rather than an endorsement of the product. 

MEGA promises users that they can choose to begin an EA project using MEGA for TOGAF, then move seamlessly to a wider implementation using MEGA Process (BPMN Edition) and MEGA Architecture. It seems as if these announcements are aligning business architecture with the technology/solution architecture centric TOGAF. 

MEGA says they will aid TOGAF practitioners in these ways:

• Ensure EA project success by following the comprehensive Architecture Development Method (ADM).
• Facilitate project communication to all stakeholders with the collaborative development of TOGAF 9 deliverables.
• Customize the implementation of TOGAF and ensure all projects deliverables are aligned.
• Build current and future state transition architectures and compare them.
• Identify, document, and publish technical reference models.

MEGA also communicates the value proposition to business architects as well:

• assess and streamline major investments
• improve customer information management
• consolidate post-merger, post-acquisition business units and product lines
• incorporate outsourced and partner solutions
• conform to compliance and audit requirements

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.