The Enterprise Application Architecture (EAA) defines the collection of application systems required to support the business processes and information needs as expressed in the Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).
There are architectural properties that are unrelated to specific application requirements but are nevertheless important. A technical architecture should show how it addresses these properties:
Perhaps a rebranding of the application section of the Enterprise Architecture, Application Portfolio Management (APM) is a healthy way to inventory, and rationalize an organization's applications.
By rationalize, we mean "to form a rational conception of". In other words, are all the applications that IT currently supports governed by reason?
Applications are assets provided their costs do not exceed delivered value.
- How can I marshal the resources required for new projects and initiatives?
- What applications are impacted by a new project?
- If we eliminate this application, what other applications and databases will need modification?
- What applications should be integrated, consolidated or eliminated?
- What applications provide redundant functionality?
- Which applications cost the most to support?
- What can I do to control costs?
- Where are we underutilizing assets due to fragmentation, lack of common definitions or lack of integration?
Resources:
There is much talk these days regarding Service Oriented Architecture (SOA) and the focus is primary geared toward software. In an SOA, modular distributed software provides services which can be aggregated and negotiated on the fly to solve complex problems. But are IT departments ready for an SOA software architecture if they are bogged down with the maintenance of infrastructure, instead of developing maintainable services.
Perhaps I am a bit off with this, but it appears to me that the proliferation of the Personal Computer has much to do with the transition from Information Services to Information Technology. So much time is spent simply providing and maintaining technology devices and the infrastructure that supports them that there is little time left for anything else.
Without architecture, there is little left between strategy and implementation. Some would say projects are between strategy and implementation. But as someone pointed out to me recently, strict project management is about doing the things the right way, not necessarily doing the right things. How do you know what to do and when to do it? And how do you make sure you have enough resources available to do more than catch up with support response?
Architecture is not infrastructure. Infrastructure relates to the maintenance of technology components to provide utility. Architecture is the the mapping of infrastructure to services to business needs; it is the definition of the information supply chain. Where has MIS gone? Who needs what information when? And how do they get it?
In the early days, Data Processing departments housed the data repositories, information was requested centrally, and experts made computers transform data into information; or in some cases only generated enough data for management to turn into useful information. Today, Information Technology departments largely supply the vehicles for users to produce and consume their own data. Somewhere between the two value-add has been lost.
What is the product that modern IT organizations deliver? Should there not be product lines, or services, which are evaluated in a similar portfolio as in a manufacturing or service company? How are those products and services evaluated for success?
Is not the success of a service partially defined as one that meets real customer needs, authenticated by increased use over time, sustained by reduced marginal cost of continued delivery or expansion.
What defines a failing product or service? One which is used by fewer individuals and costs more to maintain each year. Without removing failing products, eventually 100% of IT budgets will go toward maintenance.
So many solutions delivered by IT organizations meet a single need well, and yet shorten the horizon of future opportunities. The primary goal of architecture is to reduce complexity and thereby eliminate the inhibitors to change. Can we draw some lines that allow us to understand how today's decisions affect tomorrows opportunities?