When EA originally emerged, it was a thin layer of technology and methodology sandwiched between two large buns: business applications on the top and infrastructure on the bottom. The bulk of the headcount and budget of an IT department would be devoted to the acquisition or development and support of applications and to the investments in data centers, user PCs, network connections, and security.
This model has shifted, and one can argue that in organizations where it has not, IT is probably not making optimal use of its budget. Today, the network is usually outsourced, some of the security can be (to companies offering remote scanning services, for example), and some business systems can be rented at a price-per-user-per-month, using a SaaS model. On the other hand, managing these relationships, both technically and contractually, is something the organization should not abdicate. If IT has become a prime contractor, orchestrating the work of a number of providers and connecting their products and services according to a blueprint provided by EA, then clearly the share of the budget and headcount devoted to EA will increase.
Portfolio and Service Management
A key process within EA should be portfolio management. At a high level, the portfolio contains two types of entries:
- Projects — work in progress that is not operational yet, has a beginning and an end, and has a certain budget devoted to bringing a deliverable to completion
- Services — capabilities that result from projects and are operated on a monthly cost basis
EA should maintain a clear list of projects and services and should retain the necessary information when a project completes and the resulting service is turned on. This is usually a significant gap, which can have the following negative consequences:
- First, when examining the total cost of the service portfolio at a later date, it is important to be able to go back to the business case that justified the deployment of the service in the first place. Absent this information, it is too easy to either extend a service beyond its useful life because it is unclear what consequences stopping it might have. Conversely, it is also too easy to cut it off to save money, without understanding that it still has a justification.
- Second, when redesigning it, or outsourcing it, having access to the original business case can avoid a lot of effort duplication.
- Third, EA and IT in general should be concerned about “business case realization” — being able to verify whether the expected benefits, used to justify the ROI when launching the project, were effectively attained.
It should also be noted that most IT asset portfolios consist of entries for hardware and applications. In fact, these are the two things that can fairly easily be replaced, outsourced, put in the cloud, and so on — in other words, assets that do not really embody anything unique to the organization that owns them. The business processes and the information are the key, irreplaceable assets that capture the essence of the business operations, and should be the top priority for capture into the portfolio.
At the point when a project is delivered and a service starts, the applicable management frameworks, such as the IT Infrastructure Library (ITIL) should be used to guide service management. This may be within the purview of an IT quality function, but it could equally be part of EA. After all, mandating an architecture and standards and verifying that systems comply with them are two tightly linked responsibilities.
At a lower level of granularity, EA should also maintain a portfolio of all the SOA services and all the BPM models that can be reused by other services and functions. Each of these artifacts must be under configuration management, and each of them must have an owner. This is just basic “capability maturity” as we have known it in software engineering since 1990, but the artifacts are no longer just fragments of code.