Enterprise Architecture (EA) has promissed a thorough transformation of the business world by streamlining enterprise operations, aligning IT to business strategy and documenting the company blueprint to improve understanding, measurement and management of its operation. Although EA has been around for some time now its take off has been rather modest or inconsequential. The value it promissed to offer has not quite materialised - I hope you disagree! But what are the factors inhibiting adoption or its success? I would discuss some of the deterring factors, in the following few posts. 1. EA is frequently seen as an IT only architecture not addressing the interests of business stakeholders There is nothing wrong with an IT architecture. The issue is that the expectations promissed by the Enterprise name and advertisement are not fulfilled. This spawns a noteworthy scope issue. Most importantly it prevents the involvement, funding and support of business people and firm's management. The EA is not visible to the business side and what is more relevant it does not cover business aspects. Such an EA fails to raise interest or ultimately induce usage outside the IT and is often associated to an IT only framework as ITIL. In terms of EA implementation the IT EA team - the program is initiated by IT - has little authority to drive business architecture issues, influence corporate strategy or recommend organisational changes. Usually the EA team has little control of the business process documentation effort for instance even if successfully initiated. I have recently witnessed an EA development effort and a business process and best practices optimisation program, performed at the same time, in parallel and totally uncorrelated, by two different consultancies. IT architecture is only a part of an EA architecture. To succeed an EA architecture needs address business concerns, to be sanctioned, supported and have visibility at the business and management board level. EA needs the wider scope to include and provide motivation to business teams and enable adoption and usage. 2. Technology is only seen as IT; for a wider adoption EA has to cover all technologies No other kind of technology, mechanical for instance is considered. What about manufacturing technologies? 50 years ago there was no IT. Banks and factories still existed though. It is hardly an Enterprise wide Architecture a development which does not describe the manufacturing equipment for your products as cars, shoes etc. The IT only view is restricting the sphere of interest to just a few types of IT intensive enterprises and, inside a company, to a few stakeholders. It is again a matter of scope, not only in design but in business users' involvement, support and usage. EA approached as an IT only architecture, reduces the EA scope to IT and fails to involve business and other non-IT technology stakeholders. Enterprise Architecture is really more than IT Architecture and Technology is more than IT. ... EA is typically reduced to an IT Architecture and it does not cover any other type of technology except Information Technology. As a result it's difficult to get traction from firm's management, business or manufacturing people or, for that matter, from any other stakeholders outside IT. Yet there are a few other factors which may add to the problem of preventing a wider EA adoption. More often than not EA does not mandate architectural views - reflecting the interests of many stakeholders - or a functional architecture thus preventing adoption by a wider range of users. 3. Enterprise Architecture is overly simplified EA frameworks typically consist of four architectural layers: business, information, application and technology. The EA development is often considered finished soon after an inventory of technology is compiled, the application architecture is drawn, the process documentation is initiated by business analysts and data architecture is sketched. This leaves out other aspects or "views" of the Enterprise such as real estate, parking, accounting or, in IT, email or printing architectures though they probably exist, are documented elsewhere in some form and are of real interest to you and quite a few enterprise stakeholders. The lack of points of view reduces even more the interest and usage of EA to just a few stakeholders. Due to this simplification, EA architect positions are sometimes advertised directly for Information, Infrastructure or Applications roles in the IT space, already confining the activities to this narrow scope before the development has even started. By default the only stakeholder considered is the customer, leaving out though owners, partners, employees... views, thus limiting the scope yet again. A good practice would be to listen to stakeholders and capture their views as part of the EA architectural layers. The Enterprise discovery should be initiated by Stakeholders' interaction and needs expressed as Use Cases. 4. Frequently there is no EA functional or logical architecture view The lack of a functional architecture inhibits understanding of the Enterprise operation and of the Enterprise Architecture itself. The functional architecture outlines the key units of the firm interconnected to support your enterprise value chain and business model. Enterprise functions as Sales and Marketing, Distribution, Manufacturing, Supply Chain, Product Development, HR, Payroll ... are rather standard nowadays. The logical architecture may also help linking the process, applications and technology in a function and enable the partitioning of the EA development work. For a technical system design, the logical architecture specification is one of the first steps an architect has to perform to describe the system operation and its components. A functional architecture, added to the business, information, application and technology layers, will improve comprehension and enable organization optimisation and EA specification. It will also make possible a SOA design approach where services are built around functions. ... Not long ago I felt that Enterprise Architecture (EA) had not been growing at the pace I, at least, thought it should. I asked myself why and came up with a couple of issues. I never thought though the list would expand. I realised it does and I am not sure yet if I should quit numbering the inhibitors. This being the case, no wonder that people are reluctant about an EA development then: it may be costly, takes time and resources, its business case is not proved and the outcome may not live to expectations. What I found until now: EA is seen as an IT architecture only. All technologies besides IT seem to be ignored. EA is overly simplified to four architectural layers with no other "views" to respond to non-IT stakeholders' concerns. The functional architecture, a good practice in systems design, is not really adopted and Use Cases, coming from the world of software design, are not really used. There is seldom a link to the enterprise Value Chain or business model. And if that is not enough, there are a few more: 5. People and organization are not included in the EA scope Typically business processes or parts of them are still performed by people rather than applications. These processes, in fact more accurately workflows, are still relying on human interventions for data input, validation, phase approval... In other words they are not automated. Processes lag too because people taking decisions are away or technology fails at the hands of poorly trained personnel. More often than not the human intervention is not described in business workflows for the simple reason that people are not part of the framework. If human performance is not accounted for the overall workflow will perform as well as its weakest link, the people. But EA looks like an unfinished business without people manning processes and technology. Organization (people) design is often the object of an entirely separate and non-correlated initiative. I witnessed in a company a process and best practices optimisation effort, an organization re-design process and an Enterprise Architecture program performed by three different groups, in parallel. That is process, people and the EA activities were executed in isolation, without correlation. The organization chart should be aligned to your Enterprise Architecture so that people take ownership of EA functions, processes and technology. Culture and people communications also affect your Enterprise performance, but this is quite a topic in itself. After all, "the Company is the People" who govern, plan and operate the Enterprise. ... I have been gathering for a while now grounds for the Enterprise Architecture's lack of adoption at the pace foreseen years ago. I trust that by exploring "inhibitors", EA development obstructions would be better understood and eventually neutralised. I would also try to elucidate the scope of the EA if not for all, at least for particular developments. Every so often EA suffers from and is restricted by narrow scoping. This should be extended to reach the whole Enterprise audience with views reflecting the work of various stakeholders in business, organization, IT and non-IT technology. 6. There is no commonly accepted EA framework, the diversity of approach hindering adoption After examining the core body of EA frameworks literature I decided to count on what's left in my mind once I close the books. It is definitely a confusing scenery. Some of the existing EA frameworks are, by and large, cognitive aids asking key questions as why, what and how. A few others mainly handle implementation program management and best practices aspects. Some are mere reference models describing outcomes and implementation guidelines to serve as models for other EA developments. A few approaches are confined to BPM or Enterprise Integration only. Some specialise on domains as government, defence, manufacturing or telecoms. Most frameworks leave out people and organization ("who") or are narrowed down to business process architecture (the "how") ignoring technology. Some have been applied for a while with less than convincing results or are obsolete and used no more. Some are not taking the EA development very far. In other words there is no consensus on approach or scope. The four layers framework (business, information, application and technology) appears to be the largest common denominator for many developments. It is not clear though how or to what level of granularity the four architectures are described and how are they linked. At a minimum, the deliveries would consist of at least four diagrams, one for each layer. This may not meet normal expectations though. Now and then, a few mapping matrixes are used to link elements in or outside layers but they hardly support navigation between components or consistency in artefacts design. The four layer framework, while useful, is an over simplified approach revealing few aspects of the real Enterprise and reducing the number of EA stakeholders to a few, in IT. How do we choose a framework? Are there any recommendations for framework selection? Do you have to create your own framework? There are more than you would hope for though. Are frameworks enabling drawing of a complete picture of the Enterprise? A first check for this would be a map on Zachman's; are there all questions ("why", "when", "who"...) answered? Is the chosen EA framework fit for purpose or I would add, scope of your endeavour? All legitimate questions. To address real business concerns and to improve business and management support and participation, an EA framework should cover, besides the four layers architecture (business, information, applications and technology), people and organization, the functional structure of the Enterprise and other stakeholders' views describing aspects of work and type of information such as the real estate blueprint, financial and HR support views and document management architecture. ... nterprise Architecture "inhibitors" are, in my definition, approaches to the EA design, implementation and exploitation which do not promote further usage and limit the number of stakeholders. Amongst other, usual candidates are a lack of business and management support (because EA does not address their concerns), limited interest inside the IT function itself (since the EA scope is too narrow even for IT) and a lack of clarity with regard to other Enterprise approaches (such as BPM, SOA, ITIL...) and existing technologies (ERP). I'll touch these topics in the near future. 7. The success of Enterprise Architecture depends on EA tools EA would eradicate issues like multiple EA vocabularies, inconsistent terminology, notations, conventions or input/outputs and the proliferation of Visio, Power Point drawings or even word processing documents which generate similar issues, in documentation at least, to the ones EA aimed to eliminate in the first place, such as duplications. Usually teams design EA artifacts, reflecting own concerns, with a tool of choice. While this is not a bad practice in itself the fact is that the artifacts have no common component repository, are poorly linked, if at all, and are inconsistent with most other stakeholders' diagrams. Entities in different diagrams may not be linked to each other and may have different properties even if they represent the same component. A simple change performed by a team has to be endorsed by all other groups and propagated to their diagrams, stored in various places. That demands a considerable effort and fosters architectural data integrity issues easily avoided with a tool. Since, without a tool, maintenance of the EA is hard work, the artifacts are rapidly becoming obsolete and after that, seldom reused. With time, the EA development may change course a few times, with the outcome that EA artifacts will not implement any longer all requirements or even cover the initial scope. As such, requirements management is necessary to control the requirements churn and render the EA artifacts fit for purpose. With a potential large participation and even wider audience, web presentation is mandatory and access to the EA artifacts needs to be controlled; each team should manage own entities and produce own artifacts but aligned to and within the constraints of the EA framework. An EA tool would support consistency in definitions, inputs/outputs and look and feel by employing a single vocabulary, metadata, repository and set of architectural patterns, principles and conventions for all designs and all people; an EA entity would be represented only once for all to share and reuse. The tool would enable configuration, change management, collaboration, requirements tracing, access control and web presentation. |
|
|
EA FAQ >
EA roadblocks |