Last Updated on Monday, 07 February 2011 00:12

Many companies have a corporate/enterprise architecture group but does it mean that they have an Enterprise Architecture (EA)?

Probably the fastest way to assess this is to ask the Director or VP of Architecture to provide the Target Architectures and associated 3 years roadmaps(1). If this document is unavailable than you know where you stand!

Now, what does Target Architecture means? Typically, in its simplest form, it is a picture of the applications that will be added, modified or removed in 3 years from now. Which brings the following question; how did you get this picture?
a) Result of opinions/political views or

b) Result of having done the:

  • Modeling (documenting) of your Business Processes
  • Interactions of the Business Processes with the Common Information Model (CIM), the interactions is typically done via CRUD (Create, Read, Update, Delete) matrix
  • Mapping of the Business Processes against the Applications (which is used to identify redundant applications functionality and processes not supported by applications)
  • Analysis of which application should be kept, which ones should be decommissioned and which ones to be modified
  • Planning of the projects to get you there over a 3 year period with ROM (Rough Order of Magnitude) for project sizing and project dependencies
  • Incorporation of these projects into the annual CAPEX budget with identified sponsors

If it is based on approach a, then good luck, opinions change with the wind of the day! If it is based on approach b, then it means:

  • You have an EA Targets and Roadmaps and a plan to execute it!
  • Your architecture group covers the Business Processes Architecture Aspect (2). This group may also have defined a BPM methodology covering modeling notations, optimization, BAM (Business Activity Monitoring) and simulation
  • Your architecture group covers the Data Architecture Aspect

This is a good start! Three Architecture Aspects are covered but before tackling the other Architecture Aspects did you also standardize the Business Processes across the LOBs? This additional task allows streamlining the number of applications even more… Because one very standard output of an EA is to reduce significantly the number of applications, which brings some costs under control and the additional benefits is to have more comprehensive applications that better support the business since more processes have also been automated.

Now what about the other Architecture Aspects: Integration, Technology Infrastructure (which also includes IT Centers optimization), Architecture Governance and Security?

For the Integration Architecture Aspect, did you cover the transport layer (ESB), the Data Layer and the Process layer? Did you plan the proper software and hardware infrastructure? Did you acquire a tool that allows generation of components (API) by having all applications mapped against the CIM, which is the only way to have applications loosely coupled? For the folks who want to associate the term SOA somewhere this is it! And this is also a place where huge benefits could be achieved since you will reduce the number of interfaces, which means drastically reducing applications maintenance costs and drastically reducing new projects costs. Yes, there is some investments to make here but at some point adding applications becomes quite easy even in situation of M&A, which also brings the pre-defined standard migration plans for the M&A project, it is done right?

I will not describe the other Architecture Aspects since I am getting away from my original intent which was to address this question: ‘Do you have an Enterprise Architecture if you have a group of corporate/enterprise architects?”

If the answer is negative you probably have in place a Manager (Director or VP) of Architects who’s main job consists of assigning the best architects for the most visible/sensitive projects and who is not able to describe a vision, a strategy, a target architectures and related roadmaps, and who is not going to become an evangelist with the LOBs on the benefits of business processes standardization. Who will even question the relevance of having a tool to capture all these artefacts (metadata management, impact of change analysis, version control, roadmap mgt., etc.).

By the way, having the proper resource in charge of all the architects (solution architects, corporate architects, data architects, integration architects, capability architects, business process architects, technical architects and so on…) will force an alignment between these different Architecture Aspects and very importantly an alignment between the architects. These architects will also become more productive as they will see someone working on tackling the IT complexities to make it simpler and manageable. At the end, the quality of life at work will finally improved since these numerous crisis meetings (result of changing winds) will diminish and they will have the feeling that they truly support the business and they will also see the business succeeding!

(1) I will explain why three year roadmap in a future article

(2) The term “Aspect” comes from Capgemini’s Integrated Architecture Framework (IAF). As a member of the Open Group, Capgemini contributed in defining TOGAF 9. One way of contributing was providing IAF 4.0 as input for the definition of the Architecture Content Framework (TOGAF 9).