“Enterprise Architecture As A Service” – Why?

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

The previous TOGAF® User Group meeting was held by The Open Group in London on April 18, 2018. In that meeting, a number of very interesting questions were asked by the attendees. One topic in question was “Enterprise Architecture (EA) As A Service”.  Was “EA As A Service” considered possible, and/or useful? And if so, why? Great questions!

My immediate reaction to these questions was – yes Enterprise Architecture could, and in my opinion should, be offered through a set of services, and yes it would be very useful. An unasked question was what would it be like – but that’s another blog!

First, I guess I should describe what I mean by “EA As A Service” and the best way to do this is in comparison to something – but I am having a hard time naming the comparative scenario! Would it be “Enterprise Architecture Not As A Service” – not too helpful, eh?

So how about this description – Enterprise Architectures have been produced for a number of reasons, some bad – some good. EAs have been produced in US Government Agencies for compliance to law. In more commercial organizations, EAs have been produced to help support strategy and/or big change. The key is that the focus has been on producing an Enterprise Architecture … in my estimation an Enterprise Architecture has minimal standalone value – there has to be more for such significant efforts. “EA As A Service” is different, and much more, than focusing on Enterprise Architecture as a deliverable.

Focusing on EA as the deliverable in the traditional scenario is the first area where I compare to approaching EA As A Service. EA As A Service is about providing value for the effective and efficient production and use of an Enterprise Architecture. It’s not the Enterprise Architecture, it is how it is built, and how it is used in real practical senses!

The second comparison point lies in the perception that in the traditional approach the Enterprise Architecture deliverable comes when the Enterprise Architecture is complete. Using an EA As A Service approach is different in that value is delivered through services throughout the whole process of production and use. It isn’t value at the end, it is value along the way!

The third point is about having a better understanding of expectations. In the traditional scenario, the expectation for having an Enterprise Architecture is somewhat vague and/or can be a bit unconnected with reality. For example, if you build an Enterprise Architecture just for compliance, then you can’t expect that you will get funding just because you have an EA! Sure it may be a checkmark, but it won’t guarantee investment. So you need to ask how else will value be derived from it? If you produced it to support an initiative, then are the expectations clearly set on what that means? In my experience – not so much! With a service approach with SLAs and such there is much more emphasis on setting tangible expectations for each service provided!

Not to embarrass anyone, or organization, but in the traditional scenario the production of Enterprise Architecture often becomes an organizational entity, sometimes a long standing institution. Yet without focus on delivering value in each step of the way. Also these “ivory tower” organizations in many cases focus on compliance as opposed to enablement, and in many cases disenfranchise those necessary for realization of desired change. Having a service orientation turns this around – whether those providing the service are external or internal to the enterprise, the focus is on providing support and enabling change!

Summarizing what I feel are key comparison points between traditional and…

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

So one might ask why I think “EA As A Service” would be useful? Well there are a few reasons beyond what could be implied from the above.

Breaking up an EA project in multiple parts is necessary to ensure that value is being delivered to the enterprise constantly. Enterprise Architecture efforts must minimally support the type of development or transformation approach being taken and most modern day approaches run at an accelerated pace where value is sought early and often. You cannot wait until an entire Enterprise Architecture is completed to show value – you must break it into steps where each step delivers value.

Organizations small, medium, and large can benefit from Enterprise Architecture efforts, but only larger organizations can afford to have a permanent staff of Enterprise Architects. This has already resulted in a number of providers of Enterprise Architecture consultants – why not adopt a service model to deliver?

A service delivery model is just what ‘good fit services’ are designed to be:

• Flexible … can be molded to fit customers need
• Accessible … can be easily accessed through service interfaces (human and/or automated)
• Modular … can be modified without changing entire service platform
• Reusable … can be reused in many different enterprises and/or initiatives
• Portable … can be used in different business scenarios
• Stable … can be defined with Service Level Agreements
• Repeatable … can be delivered within well-defined timelines and within defined quality thresholds

A service delivery model for Enterprise Architecture applies equally well to external service providers as well as to an internal Enterprise Architecture organization.

Also having access to Enterprise Architecture expertise from a general service provider yields access to fresh ideas and cross fertilization resulting in richer results.

I have done a search for “Enterprise Architecture Service Providers” and they are out there – so this answers the question – “Is it possible to provide EA As A Service?” The follow up questions might be what Enterprise Architecture Services should be available and how you can identify the Enterprise Architecture Services you need.

I’ll be thinking a lot about this! Stay tuned for more blogs!

@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™.