• Project management track record. When considering outsourcing enterprise application management, companies need to evaluate how a provider performs project management functions.  In other words, you need to ask what percentage of complex IT projects were delivered within established time and cost parameters. A high percentage indicates a competent provider that can accurately manage project scope.  If the outsourcing provider’s record isn’t as strong as it should be,  you may have to spend time and money reworking projects.

• Project management expertise.  You want to evaluate the backgrounds of the enterprise application management provider’s staff.  For example, you should find out what percentage of the staff is PMI-certified.  Expert project management is necessary to successfully manage IT projects and resources. You also want to know the percentage of projects managed through a central program management office, or PMO.  PMOs ensure consistency and quality.

• Communication and collaboration tools.  Distributed projects rely on content sharing tools, real-time communications and advanced workflows.  If the provider relies on manual processes, you risk decreased efficiency in enterprise application management.  To promote the best possible working relationship, you should carefully evaluate how a service provider will work with your staff.

• Standardized internal processes.  A service provider has to understand and accommodate your company’s numerous processes.  You may be in for a rough ride if they do not have experience or a process for conducting this knowledge transfer.  It’s much easier if your organization follows a single standardized development and maintenance process that the outsourcer already has established.  Check out the audit report for confirmation that they create and follow appropriate processes and procedures.

• Managing to SLAs.  Service-level agreements (SLAs) ensure outsourcing providers meet their obligations and service commitments.  They establish mutual responsibility.  Companies currently using SLAs, or that have experience with them, will be better positioned to establish meaningful parameters with the enterprise application management provider.

• User acceptance testing. An organization should have a formal internal approval process for delivery of projects.  Prior to approval, users typically participate in acceptance testing.  This type of process is essential to outsourcing relationships. When working with a service provider, a company must be able to accept systems or changes prior to production.  Any delays on the company’s side will add unnecessary costs.

EA, as the name states, is the architecture that is the integrated blueprint of the enterprise. It, simply put, describes the enterprise from the many angles that serve its various stakeholders.

Hence, EA, as an architecture, is to be employed to
 * simplify the enterprise
 * operation improvement,
 * cost reduction
 * align of technology operation to the business wants
 * align of the enterprise components evolution to strategy
 * analyse business models
 * create an an enterprise wide transformation project portfolio
 * guide decisions and investment

In more general terms, EA is employed to ease complexity and change management.  The EA may be asked to do strategy but only for IT but this not necessarily an EA task.

The purpose of an EA framework is to enable the delivery of the EA, that is the architecture of the enterprise, rather than solving the problems of the enterprise.

The EA itself, once created, would be employed by stakeholders (clients) to achieve their specific goals such as fixing process issues, enterprise standardisation, integration, technology alignment to business operation, investment decisions, strategy implementation... in which activities, the EA architect may not be called to assist at all.

Once the architect delivers a proper EA framework and EA, he succeeds, more or less, to make own self redundant.

EA is successful if it delivers the integrated EA architecture with views for most of its stakeholders (for example top management, finance, IT development, Quality improvement etc) enabling them to achieve their own work objectives in alignment with the enterprise strategy.

If the EA team engages only in policing efforts around the enterprise, without delivering a reference EA, then the EA team failed. The EA blueprint should be used by stakeholders, as much as possible, without the engagement of the architects. The architects are not the factotum of the enterprise.

But the definition of the EA states more than its purpose. It has to answer the What then other W like questions such as Why, Who, How...

It denotes the EA practice that should collaborate and coordinate the many other activities in an enterprise to discover, design and implement the EA and the enterprise target state.
EA also means the EA team that manages the enterprise.