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.

Interdisciplinary Design as an Instructional Discipline

I was invited to speak on a panel discussion entitled “Interdisciplinary Design as an Instructional Discipline” at the National Science Foundation (NSF) Engineering Research and Innovation Conference in Honolulu, Hawaii. The theme of the workshop was to foster creativity and innovation in approaches to design by including it as an instructional discipline in academic institutions. Therefore, panelists and invited audience from diverse backgrounds such as architecture, business, product design, information systems, etc. were engaged to provide their perspectives on the design process. The discussion, led by senior industry decision makers from Siemens, Honeywell, PetSmart and Dansk, provided an interesting perspective on issues and challenges facing today’s global and economically turbulent marketplace.

It was interesting to note how the process of design is conducted in disciplines other than information systems and software engineering. There were quite a few commonalities but then there were obvious differences as well. Almost all of the fields do have a multi-step process consisting of conceptual, logical, and physical designs. The difference lies in the interpretation of what constitutes each of these design sub-processes.

I will not elucidate on the design issues that were pertinent to other areas but I will be remiss if I do not highlight the design issues facing our industry today:

We need a design process that consistently facilitates the alignment of the implemented systems with the intent of business. Despite our best effort in trying to come up with a workable design, the rate of failure of IT systems (maybe not systemic failure but nevertheless significant failure) today is quite high. Why is that so? Is it because we err in gathering, analyzing, and/or comprehending the requirements of our business partners? Or is it that our design process is flawed that we fail to realize our system deficiencies well in advance of implementation.

How do we ensure integration in terms of business rules, standards, information flow, process flow, interoperability, etc. across the enterprise? Today, it is not uncommon for businesses to be spread across a much wider geographical and cultural spectrum. Consequently, the varied nature of our system boundaries poses a much greater challenge in integrating our process flows. Could we adjust our design process to take into account these seemingly extraneous factors?

How do we facilitate easy change with the ability to quickly react to market? With the advent of the information age, the market is a much more dynamic entity today when compared to a time twenty years ago. Therefore, not only does our design processes need to be sound but they also need to facilitate a quick entry to market. As the market conditions are forever changing, the design process also needs to be flexible to optimize systems development and maintenance.

How do we ensure all of the above and yet keep pace with increasing technology and programming paradigm sophistication? Adding to the other challenges, the constantly changing technology landscape with increased sophistication in technology paradigms sometimes provide a disruptive influence that needs to be countered to ensure a stable software development process. We can, and should, embrace these new developments but certainly not at the cost of disrupting the enterprise. We are here, after all, to serve the business and no amount of tectonic paradigm shifts should alter our basic focus: supporting the enterprise.

Can we perhaps incubate these ideas into future generations of software designers if academic institutions were to encompass them into a design instructional discipline? Or should such things be learned experientially rather than being advocated in a formal instructional setting?

On the long flight back home, it certainly made me go, “Hmm”.