Real Time SOA - Planning Your SOA

Service Oriented Architectures (SOAs) have been all the rage in the world of computing for quite a while now, and many companies have had great success while others have had failures.  As with all things in life, planning is key when approaching a SOA, and also like so many things, planning must be taken in moderation.

Frequent readers have likely picked up on my love of games, board games, console games, PC games, even Tabletop RPGs.  I am in love with the dynamic of engaging with a group of people in a fictional model of something. While attending a recent event put on by Sogeti about realizing success with SOA several corollaries clicked into focus for me between SOA and the type of games called Real Time Strategy (RTS) games.  This article is the result, I hope you at least get a laugh.

I'm sure more than one of you is now saying: "Real Time Strategy games are like an SOA?  Tim's popped a gasket."  But let me make my case.  In an RTS is a simulation of a struggle between two or more people to achieve dominance in a environment with limited resource availability. Most businesses (not all) are attempting to achieve dominance in a market with limited funds and other resources.  As such, since an SOA is supposed to digitally represent the core competencies of a business, it is reasonable to say that SOAs likewise are trying to move a business towards dominance in a market with limited funds and resources.

Now when planning a SOA, before you've implemented your first service even, you are much like a player who has just started a match in an RTS game.  You've likely got a small amount of funding (likely peeled away from one project or another) and one or two developers that you can have begin to work on things.  Ah, and you have your first complication as well.  The staple of the RTS genre known as the "Fog of War".

The "Fog of War" in an RTS game is a sheet of black or gray that covers any area you've not explored or cannot see currently because you have no units there.  In our comparison, this is the uncertainty of where to begin.  Somewhere out there in the fog are high value resources that will move you towards your goal, such as Gold Mines in an RTS or key areas of flexibility which open new markets in a SOA.  The problem is you don't know where.

Hence we come to the first and most important step of an SOA, planning. Different ideas have been espoused for dealing with this dilemma, we will look at those now and their RTS comparisons to see which we think we actually let us win the game best.

• "The Big Plan" - Perhaps the most popular with large corporations, this plan states that the most important thing to know about a SOA is exactly how to build it right the first time.  In RTS terms, these people want to spend a lot of time exploring the entire map so they know where all the key resources and pitfalls are before they begin to build out their game.  The problem with this is cost, not necessarily in dollars/gold (though it can cost that as well) but instead the cost of opportunity. This plan spends so much time planning that it is possible that by the time they've decided to start playing, someone else has already one.
• "Just Get Started" - In opposition to this idea, many shops (often smaller ones) try to simply start building.  They will not explore the unknown areas around them, they'll simply start building services without ever getting a lay of the land.  Those builders are your developers/IT and they are well meaning, but they are not spending enough time interfacing with business, who cares about the big picture and clearing our fog.  The results of this effort may be highly technically competent and well architected, but may be providing the entirely wrong type of resources to drive the business because they are not aligned with business.  Nothing ruins a beautiful SOA more than a sudden and unexpected attack from a horde of Zerglings.
• "Just Enough Planning" - Obviously the key to finding middle ground between these two extremes is moderation.  We must gather resources and begin to build, but we also must explore the fog and find new opportunities.  What is needed to make both these things possible is a high level understanding of where we want to go.  In real world terms, this takes the form of a document which specifies the core competencies of the business.  These are the silos that constrain IT's development, directing in the way that victory is being pursued.

In RTS terms, we're trying to make sure we're gathering the right resources, so the right types of things can be built and areas explored. As you build to the high level plan, you'll be exploring new areas, clearing away the fog and providing details.  Will this mean that you might stumble upon problems or unforeseen opportunities? Yup!  But that just means you need to plan for change ... but that's another post.