Over the last decade or so there has been an emergence of techniques and skills that are generally referred to as “Extreme”. We use the term in everyday life to refer to activities that push us to the limits of our abilities and test our mettle. In the IT industry we have been using the term to cover a gammut of concepts such as Agile, Flexible and Dynamic.
At the same time, and possibly driving this trend, is a counter balance that is attempting to ensure that what gets delivered to the end user is exactly what they asked for and so the methodologies have become increasingly more complex and lengthy. This has led to project timescales lengthening and the consequent knock-on effect of a mismatch between what is delivered and what was requested. Service providers in every walk of life are seen as being slow and pedantic because they are measured by the final outcome and its fitness for purpose. Users, on the other hand, are used to the current trend in web-based technologies to be able to create web pages, customise their portal interfaces and order goods online in seconds. The contrasts are marked, obvious and confusing.
Architecture – Enterprise Architecture as well – is suffering the same dilemma. On the one hand, we, as IT architects, need to be able to stand in between the business and the delivery arm of a project and assure everyone that the results of the activity will be fit for purpose and meet the needs of the supplier and the end user. On the other, providing that level of assurance doesn’t happen overnight and I am sure that we are all aware of the problems that have been created in the past by missing some vital piece of information.
The challenge is to build an assurance model that is both thorough and agile. My gut feeling on this is that this can be achieved with a high degree of success and a certain amount of discipline. It comes down to a couple of key, simple to implement ideas;
- The need for Patterns and old fashioned building blocks and
- The need for checklists and record keeping.
Once we have an Enterprise Architecture Framework in place (aka Reference Architecture) and then build on top of that a culture that assures each project based on a checklist of criteria, then we are getting to the point of implementing something that can be “light touch”, “Agile” but thorough. The Checklists will ensure that we quickly zero in on where the real issues are within a solution design. If that is divided up into Business, Information, Application and Infrastructure Layers then various reviews can look at each section and key Architects can be involved in discussing and reviewing the solution based on the exceptions.
The Checklist approach is part of the Extreme Architecture Assurance model and is designed so that the review can “learn” from previous mistakes and also can track each project and provide relevant metrics. It “learns” because when a mistake is made, the checklist can be updated to ensure that the problem doesn’t happen again. The checklist is also made up of simple answers which means that they can be logged on a database to report on how compliant each solution is.
Clearly this is a simplified view but is based on the 80:20 rule. 80% of the architectural issues in projects can be surfaced by a methodology that takes up 20% of the current architectural effort. We all know that it is that last 20% of effort “where there be dragons”!
