One thing that comes through from my SOA Governance talk last week: SOA Governance is a set of processes that starts in the early planning stages and crosses through to operations. 

So, with Governance in the back of my mind, I was reading up on some of the work done by various authors in the area of Service Oriented Analysis and Design to understand some of the formalisms that have been proposed.  I wanted to see how others were addressing the planning governance space.  Unfortunately, they all start from the wrong spot.

SOAD starts from the same place as OOAD starts.  There is an assumption that the business wants an application to come into existence and the architect is then brought in to solve the problem.  It is a very project-focused solution.  It is like a business owner buying a plot of land in a city and calling an architect to help him to build his five-storey office building. 

That is the wrong spot to start SOA work.  For SOA to be useful to the enterprise, the services must span applications.  They must be visible outside the scope of the app, but used by them.  In the ‘city’ example: Services are not the foundations of a single building.  They are the electric grid that all the buildings use. 

And not just an ordinary electric grid: imagine an electric grid where every building generates power according to the amount of light and wind that comes to the plot.  Some buildings will supply power and others will comsume it.  Making that kind of grid function cannot be done after the land owner decides to build the building.

SOA has to be built long before the application owner decides to build the application.  There has to be infrastructure in place: patterns, messaging, MDM.  More importantly, there has to be a plan in place for that ‘site’ where the application will sit.  What applications are already in place in the enterprise?  What services do they offer?  What services SHOULD they offer?  What overlaps are you introducing?  How will your data be found?  How will it be secured?  This is the realm of SOA planning.

Starting with the building plan is too late.  SOA needs to start with the city plan. 

So when we talk about Service Oriented envisioning, let’s not start with Analysis and Design.  Let’s start with an entire regimen around Service Oriented Planning, Analysis and Design.  SOPAD.  We have to know where the services belong before we build them.  We have to know what they need to do before we write them.  We have to know how to keep them running before we deploy them.

And then we get to the tail of this dog.  We have to run our services in Operations and we have to Govern our services to insure compliance.  Service Oriented Planning, Analysis, Design, Operations, and Governance.

The term is not SOAD. 

It is SOPADOG: Service Oriented Planning, Analysis, Design, Operations, and Governance.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

6 thoughts on “Why "Service Oriented Analysis and Design" Starts Late and Ends Early”

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × 3 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.