“Enterprise Architecture As A Service” – What

By Terry Blevins, Fellow of The Open Group, Enterprise Architect at Enterprise Wise LLC

In my previous blog, I described why “Enterprise Architecture As A Service” (EA As A Service) would be a good thing. Fundamentally because a properly implemented service delivery model would put the emphasis in more appropriate places:

• Production and use value versus EA as a deliverable
• Timely value along the way versus at the end
• Clear expectations versus vague promise
• Support and enablement versus ivory tower compliance

In that blog, I mentioned an interesting question for a future consideration, what would “EA As A Service” be like? This blog provides some thoughts on that question. I’m going to approach this from two perspectives:  the customer perspective and the supplier perspective.

“EA As A Service” Customer Perspective: The Need

A typical customer that is questioning whether they should leverage Enterprise Architecture is facing some significant change; possibly due to recent success or perceived failure. Recent success results in organizations having to deal with big decisions on ways to invest and maintain their success. Perceived failure results in a need to make decisions to address the failures. Each of these scenarios gets attention during the strategic planning process and, as pointed out in “Enterprise Architecture as Strategy” by Jeanne W. Ross, Peter Weill, and David Robertson, Harvard Business School Press, 2006, EA is a useful tool.

The bottom line is that big decisions are looming and there is a perception that EA can help by defining “the organizing logic for business processes and IT Infrastructure, reflecting the integration and standardization requirements of the company’s operating model” so that “individual projects can build capabilities – not just fulfill immediate needs”.

But there is another, less positive, perception out there – EA can be a money sink! It could result in tons of paper, take years, result in something outdated by the time it is finished, just to name a few concerns. Also the need for change has a timeline shorter than the perceived timeline of generating an Enterprise Architecture. The bottom line here is that there is fear, uncertainty, and doubt about Enterprise Architecture being a waste of time and resources.

So what do organizations need to do to reap the benefits and avoid the pitfalls? Well in my opinion:

1. They need to demand Enterprise Architecture efforts are purposefully directed to deliver value.
   • Through value delivered at each and every step of the way rather than waiting for an Enterprise Architecture to be “complete.”
2. They also need to demand a focus on empowerment and enablement for the initiatives of the organization.
   • Through Enterprise Architecture efforts that specifically provide guidance and tools to make it easier to deliver on the initiatives – to build capabilities.
3. They need to demand support for the cadence of the organization.
   • Through just in time delivery of information and guidance along the journey.
4. And lastly on my list is they need to demand support for decisions.
   • Through Enterprise Architecture information that is pertinent to specific decisions on the table.

In other words, the value isn’t in having an Enterprise Architecture – it is using an Enterprise Architecture that is fit for purpose!

As proposed in the prior blog, I believe that a service delivery model is a good model to deliver offerings for the above in contrast to having an Enterprise Architecture.

“EA As A Service” Supplier Perspective: The Offer

The offer is not handing an organization a completed Enterprise Architecture. The offer is a set of services that provide just enough help a customer in their EA journey in the time of need.

A good way to present services offered is through a catalog created to resonate with customer needs. The key is to make it easy for perspective customers to find the type of service, or services, they need. For contrast consider the following two ways to list an offer:

• Example 1: EA Builders: we build and deliver Enterprise Architectures
• Example 2: Planning Services: we will scope an EA effort based on your organization needs

Example 1 presumes that a customer is looking to have an Enterprise Architecture built and begs many questions including the most important – if an organization had an EA could it take advantage of it? Example 2 is more helpful in that it helps those customers that aren’t sure they need an EA, rather they need help understanding whether an EA could be of use to them.

I think the following categories of EA services is a useful way to capture the types of services of an “EA As A Service” provider based on customer needs. For each category, there are a few service examples in the sub-bullets. (Note that this list purposefully doesn’t include services for developing Enterprise Architecting capabilities or building an Enterprise Architecture organization – that’s another story!)

• Planning Services to scope based on need
  1. Architecture Expectation Development Service
  2. Architecture Project Plan Development Service
  3. Concept Evaluation Service
  4. Project Management Consulting Service
• Buy-in/Collaboration Services to ensure the right people in the organization are engaged
  1. Requirements elicitation Service
  2. Architecture Workshop Facilitation Services
  3. Tradeoff and Risk Management Service
• Development Services to build the right parts of an EA at the right time
  1. Architecture Vision Creation Service
  2. Architecture Inventory Service (Archeology Service)
  3. Capability Roadmaps Support Service
  4. Gap Analysis Service
  5. Process Optimization Service
  6. Architecture Development Services
• Management Services to ensure that the EA efforts delivers value consistently
  1. Architecture Repository Consulting Services
  2. Architecture Assessment and Review Service
  3. Contractor evaluation Service
  4. Earned value understanding and analysis service
• Usage Services to derive value from the EA
  1. Migration Planning Service
  1. Capability Assessment Service
  2. Portfolio Optimization Service
  3. Enterprise Architecture Analysis and Report Services
• Decision Support Services to support Portfolio Governance decisions
  1. Governance Consulting Service
  2. Compliance Creation Service
  3. Program Compliance Evaluation Service

For each of the categories above, a catalog would list the individual services and provide enough information for each to inform prospective customers. Each service entry should describe the service in terms of targeted problem addressed by the service, value delivered, costs, expectations on the customer side, service level thresholds, and the mechanisms to access the service.  It would be useful for the service provider to list the experts and qualifications of those that deliver the service and, as well, the methods employed and standards supported.

As commented in the prior blog, the service delivery model for Enterprise Architecture applies equally well to external or internal Enterprise Architecture providers. So whether the organization helping with Enterprise Architecture is outside or inside the organization, providing Enterprise Architecture services is an appropriate way to deliver the offer.

I hope this blog is useful to those that wish to leverage Enterprise Architecture to improve their organization by informing them of the needs to raise their expectations and demands from EA efforts. And I also hope this Blog is useful to existing, or new, Enterprise Architecture providers and consultants for establishing, and advertising, Enterprise Architecture Services that deliver value to customers in contrast to just delivering an Enterprise Architecture.

Please stay tuned for the next blog in this series – “EA as a Service” – How.

@theopengroup

Terence Blevins, a Fellow of The Open Group, is owner of Enterprise Wise LLC and a semi-retired Enterprise Architect. He is currently a Director of The Open Group Governing Board and an active contributor to the Healthcare Forum within The Open Group.

Terry has been involved with the architecture discipline since the 1980s, much of which was done while he was Director of Strategic Architecture at NCR Corporation. Terence has been involved with The Open Group since 1996 when he first was introduced to The Open Group Architecture Forum. He was co-chair of the Architecture Forum and frequent contributor of content to the TOGAF® framework including the Business Scenario Method. Currently he is excited to help the Healthcare Forum work on Boundaryless Healthcare Information Flow.

Terry was Vice President and CIO of The Open Group where he contributed to The Open Group vision of Boundaryless Information Flow™.