Sunday, September 15, 2013

How to Assess the Quality of Architecture?

Enterprise Architecture is the art and discipline of designing enterprises. Take architecture as a way of thinking and embodies the quality of human thought. We can construct without design but we elevate construction by design. In turn we elevate design through architectural thinking. The careful consideration of requirements in design along with an overarching vision is what a good architecture represents.

To create a starting point, perhaps we should focus first on defining and agreeing on what quality actually means when it comes to Architecture. This is likely to be non-trivial. Here are a number of dimensions that might be used to define architectural quality:

Usability - how readily available and accessible are architectural descriptions that people actually use regularly

Craftiness or lack thereof : How mature the architecture design: functioning, firm or delight?

Coverage - how well do the architectural assets cover the entire scope of the organization, from scope through to the operations layer?

Navigability - how easy is it to find your way and jump from place to place in the architecture repository (based on various types of associations/relationships between elements)?

Scalability: A good architecture should be able to respond to the times and that can mean a growing or shrinking company. It needs to do the things it knows quickly and efficiently.

Changeability: EA quality should in particular focus on the result of the change. And since we look to the transition and state transformation of the enterprise, we should try and measure the desired outcome versus the negative Impact of the EA program. Since an enterprise has architecture, we need to make trade-off decisions in our interventions and these have outcomes and impacts

Agility: Agile EA is about impactful choices up front that will make later choices easy. Agile EA is about stable ground, but not frozen (static) ground. Agile EA emerges over time, incrementally think about the future, but doesn’t overbuild the architecture. Agile EA is highlight which changes to focus on, which one can be ignored; Agile EA is to be open about your architecture — encourage criticism, allow requirements to drive your architecture updates.

The Vitruvian Virtues of Architecture: Utilitas, Firmitas, Venustas
1). Venustas: Aesthetics - In an Enterprise, think of quality of People. The synergies and dynamics of human values, culture, beliefs, intellectual capital, relationships, etc. and the quality of customer relationships and experiences.
2). Utilitas: Purpose/Function - In an Enterprise, think of quality of Process. The overall performance of organizational units, efficiencies through automation, flexibility of inter-dependencies, etc.
3). Firmitas: Structure - In an enterprise, think of the quality of Systems. An enterprise as a system represents collective but also that systems as information and technology and infrastructure. The quality of the information, tools,  platforms and assets, fit and appropriateness of technology, location etc.

Manageability: there are four areas of management: Managing the Enterprise (strategic, corporate office, analytics/BI, HR, Finance, etc.), Managing Innovation (ideas to implementation, R&D, product life cycle, etc.), Managing Operations (manufacturing, logistics, etc.) and Managing Client/Customer (marketing, relationship, service & support, etc.). The quality of EA in alignment is across Managing the Enterprise to Managing Operations. If an organization is scaling and maturing, the obvious process gaps in the architecture of an enterprise lies in this area. Often the most neglected areas of EA are in managing the product innovation and customer experience. Each enterprise will have different imperatives but if an enterprise needs to deliver new products or create new channels to increase the range of marketing to customers, the quality of the architecture should be based on indicators that measure the effect in these areas. 

Traceability: The architecture has to describe all of the current deployment technology patterns, and that must have a traceability matrix from requirements to process to information to physical implementation. To understand whether the architecture is 'good' or 'bad' or somewhere in between, and a lot of color between white and black of failed and perfection, all you need to do is look at two key business metrics:
1). The operating ratio (complexity, maintenance vs. new dev, sustainability, etc.)
2). Time to market (business partnership, requirements elicitation, testing and operating platform efficiencies, etc.) 

The quality of the architecture is also dependent on its flexibility - the alternative ways to do things, . Integration (ease of) should also be considered, given the need to link externally and potential mergers and consolidations. 


Post a Comment

Twitter Delicious Facebook Digg Stumbleupon Favorites More