What Peter Kemp and John McManus complain about in the March issue of ITNow is not enterprise architecture as a subject, but instances of badly-practised enterprise architecture. As they rightly say, the concept of enterprise architecture - tackling a business's IT portfolio from a [business] strategic perspective is just what the IT world has been waiting for.
As with any emerging profession, professional standards are not yet widespread and a lot of EA teams lack the relevant knowledge, skill or experience to avoid the bad practices. The caricature of enterprise architecture they so condemn is a straw-man composed from instances of bad practice.
Take the first example: 'We can't make progress on anything until we've rewritten everything in Java.' This is obvious nonsense and should make the audience question the competence of an EA team making such assertions. The team in question had made several well-known EA mistakes: they had fallen for the architecture myth that 'architecture is just X technology' - a myth that is explicitly identified on at least one Enterprise Architecture training course. A rewrite in Java suggests application architecture, not EA, thinking.
This is a half of stage C of the eight stage TOGAF architecture development method; this EA team mistook a small part for the whole thing. A target architecture is also much more than an identification of software components and the language in which they are coded. The information systems architecture - TOGAF ADM stage C - is derived, according to good practice, from the business architecture.
What possible business architecture could lead to everything being rewritten in Java? It is a rare business that cares, fundamentally, what language its software components are developed in. The EA team in question was being technology-driven - exactly counter to the business perspective that EA good practice promotes. TOGAF stage E is identified the changes in the IT landscape based on business value and a gap analysis between current and target architectures.
There could be no roadmap leading to a 'sea of Java components' that made business sense. An enterprise architect also knows that a 'rip-and-replace' strategy, like a rewrite in Java, is unlikely to lead to minimum medium-term IT costs - so not usually good EA strategy.
So, an EA team that could make such assertions is a team that is not well-trained and knowledgeable in EA.
Yes, just an example of enterprise architecture done badly or, more likely, enterprise architecture in name only.
One or two examples do not a general case make, but is there a systemic failure in enterprise architecture, as Kemp and McManus imply? Let's look at their characterisation of EA:
Technology-led, nominal standardisation
Being technology-led is exactly counter to the EA ethos. All technology developments and changes are supposed to be related back to business drivers through EA. Standardisation though important should be far from 'nominal'.
Standardisation is there to prevent unnecessary and unaffordable duplication-of-functionality and excessive technological diversity. Standardisation and technology driving business-change is exactly counter to recommended EA practice.
Dogmatic
Enterprise architecture principles and standards are justified by explicit rationales or logic behind them. But a standard or principle is just that - firm guidance not an absolute rule that must be followed slavishly. Should a project team believe it has a case for an exception to the standard it should make the case.
If the logic is sound, the EA team will have no choice and permit the exception. An end-user requirement on its own, however, is not enough - the requirement itself has to be justified in business terms. There are two reasons why EA might appear dogmatic: the EA team really is being dogmatic and that the EA team is being effective in making development teams justify their technology decisions.
Over-ambitious
A target architecture is supposed to be just that - a target. EA as a discipline is supposed to look to the strategic development of the business. Targets should be ambitious and maybe a little utopian. An experienced EA knows, however, that a target architecture may never be reached - external developments may change the target before it is hit.
What stops this from being a futile academic exercise is the roadmap derived from the gap analysis between the current and target architectures in TOGAF stage E. A little ambition, tempered with realism and pragmatism, is no bad thing but EA is more the direction than the destination.
Unverified
Enterprise architecture includes assessing the capabilities of the organisation to do systems and software development and operation. The target architecture should be self-referent - it should assess its own achievability by examining the changes will be required in the IT department.
Its sustainability should be assessed by asking about changes in the service delivery and management parts of the organisation. Furthermore, target architectures in programme blueprints must be shared among the stakeholders and, especially, the programme's business change managers. If the EA strategies/ roadmaps etc. remain unverified that is a communications failure - not a failure of the EA discipline.
Divorced from the current state
In TOGAF the current state (architecture) enters the picture through the gap analysis with the target architecture and feeds into roadmaps that indicate the transition steps. No transition plan means the team isn't really doing enterprise architecture - just pointless speculation about what a future state. This is again a failure of the team to follow good practice, not a failure of the method or the EA discipline.
Futuristic
Target architectures are by definition in the future. EA roadmaps and strategies should cover the significant developments and intermediate architectures between today's as-is architecture and tomorrow's to-be architecture. Good EA practice promotes the production of such artefacts and these provide the next steps guidance. Individual EA teams may fail to produce these artefacts but this is not a systemic failure of the EA discipline.
Politicised
A political aspect to enterprise architecture is inevitable. Politics is about balancing the interests of stakeholders. Different parts of the organisation will have different interests to be balanced in EA strategies and architectures.
The ethos of EA, is to make this balancing explicit, to make the rationale behind decisions clear, to make them objectively justified and to get away from traded opinions, prejudices, perceptions and 'sound-bytes'. EA should provide the hard analytical basis for objective decision-making to make the technological development business-aligned and justified. EA as a discipline is a force for de-politicisation of IT development.
One or two bad chess players, who fail to take into account their current position, does not mean there is a systemic failure in the game of chess. Examples of badly-done enterprise architecture do not mean there is a systemic problem with the discipline. There is no reason to think all EA efforts will be so characterised and reasons, within the discipline, to think they will not.
Is EA prone to impracticality?
Is it practical for a business executive management team to work at the enterprise level without working on specific business problems? Is there not some difficulty in applying abstract concepts like Porter's generic strategies and the McKinsey 7S framework? Are not business strategies for ever-increasing market shares and continually fast-growing shareholder returns impractical?
The devil is indeed in the detail. Just as business management is a challenging and difficult discipline, relatively easy to do at the conceptual level but very difficult to apply practically and produce success so it is with enterprise architecture. Like business management it takes some years of study and many years of practical experience, at various levels of responsibility, to do well.
This does not mean a centrally-planned economy any more than it means that every operational decision in a business must be made by the executive management team. It does mean that effective governance must be in place to ensure the right decisions are made for the right reasons by the right people.
An EA team out-of-touch with the 'real world' is indeed a bad thing, but it should not happen. The enterprise architects should be talking with the technical architects on projects at least through the formal governance mechanism if not informally. Should a non-compliance be justified at detailed design, it should automatically be flagged back through governance and raised directly and immediately with the EA team.
So, we reach the same conclusion: not a systemic problem with enterprise architecture as a discipline - but there may be problems with the way EA is 'done around here'.
Another problem
Excessive technological diversity, multiple silos of replicated functionality, unintegrated and duplicated systems are expensive and unnecessary, and make IT costs higher than necessary. Consolidation, integration and rationalisation may well be the appropriate strategy. However, consolidation does not necessarily mean one multipurpose application and integration does not mean tightly-integrated.
The constant business demand for IT flexibility is met by the constant EA mantra of loose coupling. In the ideal, individual software and hardware components can be substituted and swapped-out, developed, extended, enhanced, changed and decommissioned without enterprise-wide impact. Done well enterprise architecture should tend away from the inert, ossified software.
Zero diversity in solutions is not a tenable strategy either. The aim of EA is to move the organisation to the right level of technological diversity. IT departments left to their own devices have a history of excessive diversity. Project teams are not in a position to judge - what is required is cross-project, enterprise-wide coordination - enterprise architecture.
The benefits of enterprise architecture are potentially enormous, but it is highly dependent on the quality of the EA function. Done well enterprise architecture is an invaluable help to any organisation in effectively executing its strategy. It is also tremendously facilitative for systems development. Done badly, Enterprise Architecture is at best futile and at worst an impediment to making progress.
Whither enterprise architecture?
Towards greater professionalism, increasingly widespread good practices, higher-quality delivery, more aligned business and technology and higher business value to organisations. Hopefully!
