Developing EA in the context of managed services

This article first appeared in ebizq and is being reproduced here:

When practitioners refer to examples of Enterprise Architecture (EA) programs, they generally refer to in-house initiatives run by a business’s IT department. Therefore, the objectives of such programs are grounded in the business’ self interests. In the case of Managed Service Providers (MSP), who not only run their own enterprises but also the IT departments of their customers, the objectives are dual and sometimes competing. In this article, I attempt to differentiate between these two kinds of EA programs and look at ways in which an MSP can not only help themselves, but also their customers. First, let me begin at the beginning by defining EA and MSP.

Different experts give different answers in defining enterprise architecture. But there a number of commonalities in their definitions. There are technology and business architecture components that are the backbone of most frameworks. There is also a strong information architecture component in some of the more practical frameworks. In the interest of brevity, I will quote only one definition from Gartner, which defines EA as:
Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.

An MSP, for the purposes of this discussion, is defined as a provider who provides services (both delivery and management) in the areas of network, server management, application maintenance, infrastructure maintenance, and hosting. A total service provider usually contracts for a Walk-In-Take-Over (WITO) type of an arrangement.

Today, EA services are generally provided by the IT department (the discussion of the wisdom of this is a subject of another article.) An enterprise architect program typically reports directly to the CTO/CIO and is headed by a senior enterprise architect. The function of this group is to understand the business, facilitate the alignment of IT with the business, and ensure that IT services are provided to support both the tactical and strategic operations of the business. As part of its mandate, the EA provides policies, standards for maintenance operations, and guidance for adopting new and emerging technologies.

This works well when you have an IT budget of sufficient size and--more importantly--the people to help implement the EA program. But what happens when the CIO decides to totally outsource IT operations to an MSP? Who runs the EA program when you have little or no influence on the technology component? While the CIO might still retain key people to interface with the MSP and the business, it is usually not an effective arrangement.

Contrast this with the EA program of the MSP. It is a dual objective program in that it needs to serve both its business and the business of its customers. This requires the creation of two charters; one internal and the other for its customers. It may look and feel like a duplicate program, one where every deliverable seems to come in two flavors – internal and external. The reality, however, is that for a program to be effective and practical, the MSP needs to have a generally common EA program that is applicable to both its internal and external customers. There may be minor tweaks here and there but the net intent and direction of the program should remain the same. (Note that this does not apply to the governance structure of the EA program, as it is something that should be tailored specifically to each customer).

To practically develop the EA program in a Managed Services scenario, it should be led by a chief enterprise architect with a number of enterprise architects reporting to her. This pool of EA will ideally come from backgrounds with vertical strengths (i.e. energy, healthcare, insurance, biotech, automotive, etc.) Each of these EA’s are then assigned to one or more (ideally two) customers in the same vertical. By rotation or otherwise, a similar pool of EA’s can develop the internal institutional capital of the MSP EA program. These artifacts/knowledge capitals are then filtered down to the customer level with the appropriate tweaks to maintain relevance and suitability.

While implementing such an EA program is not all that difficult, the issue is convincing the end customers of the sincerity of the MSP’s EA services. The typical contact point in an MSP relationship is between the account executive of the MSP and the delivery head/CTO of the customer. It is a challenge for the MSP to get beyond this relationship and gain access to the business side of the customers. Generally, there are two reasons for this: one is that the customer’s IT head feels the need to act as a go-between the business and the MSP to ensure continued relevance of their position (essentially job security); two is that the customer’s IT is in a better position to understand its business than the MSP (vertical/domain comprehension). While these may be valid reasons, the customer would actually gain from allowing access to the MSP enterprise architect. This person would likely have had experience in similar domains and can bring a great deal to the table in terms of process efficiencies, identifying deficiencies in information systems, and recommending optimization strategies.

To illustrate my point, I offer two case studies. In the first case, the MSP recently established a contracting relationship with a customer who recently divested from its parent company. As is usually the case, the relationship between the recently-divorced parent and the new entity was acrimonious. Being a nascent company, the customer was initially unwilling to let the MSP communicate with the divorced parent. Therefore the MSP initially stayed out of the contentious issues and let the customer lead through these technical discussions. Since this was a new experience for the customer, they did not ask the right questions and anticipate issues before they arose. These management errors led to cost overruns and project delays. In desperation, they finally asked the MSP to take a more active role in managing the relationship. The result is that the MSP was soon able to get things going in the right direction. These and other value-added services provided by the MSP above and beyond the contractual obligations, eventually gained the trust of the customer who then asked that the MSP EA sit in on strategic meetings between the business and IT of the customer.

In another case, the issue concerned a well-architected but poorly executed project. As in the previous case, the MSP had no access to the business partner of the customer. Again, by stepping up to the issue and taking the responsibility to rectify the project, the MSP gained the trust of the customer’s IT department. The MSP certainly generated additional business because of this project. But overall, the relationship improved significantly, due to an effective inclusion of the MSP in the business-IT strategy meetings of the customer.

As these examples indicate, it is always in the interest of the MSP to provide the value-added services to any ITO relationship. Merely serving the letter of the contractual arrangement does not establish a long and fruitful relationship with the customer. At the same time, customers need to realize that it is in their best interest to engage MSP earlier in the contract to help them make sound strategic technology and business decisions.