Baby Steps to SOA – Step One: Analyze and Plan

In the continuing Baby Steps to SOA series, we follow Doug and his IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Previously, we introduced the problem and the team, and now we start on our travel through the road map.

The Evolutionary Roadmap

• Step One: Analyze and Plan
• Step Two: Measure It
• Step Three: Three Tiers for the Website
• Step Four: Single Sign-On
• Step Five: The Move to a CMS
• Step Six: Data Services
• Step Seven: Centralizing eCommerce
• Step Eight: Sharing the Business Tier
• Step Nine: Moving beyond the website
• Step Ten: Riding the ESB

Step One: Analyze and Plan

The team will actually be planning at every step (we are agile, aren’t we?) but before the team starts they need a high-level road map. This plan will allow the team to understand what steps are going to be taken, and which systems are going to need to be altered.

Analysis

Before even thinking about the plan, the team needs to analyze what they have already. The team should collect all of the systems they currently maintain and determine which systems connect to each other or have dependencies on each other.  The focus here should be on the business assets, and not the physical infrastructure.  For example, an intranet website may be composed of several content delivery nodes, database servers, and backup infrastructure, but for the analysis purposes it is all composed in the single “Intranet” business asset.

In our scenario, Doug has asked Lynn to create some high-level architecture diagrams for the team to review.  The diagrams need to show the interdependencies of all of  systems currently in existence.  After several days of combing through the various digital assets and asking questions to the development and QA teams, Lynn has put together the following information to show what currently exists from a high-level digital asset view:

While Lynn was doing this, Doug was busy pulling together data on their budget spend from the last year.  Unfortunately, the timesheet system was not set up for Doug to see which system his team was working on throughout the year, but since most of the projects targeted a single system or perhaps two, Doug decides to pull his financials together based on project and then split them across the systems involved in the project.  This allows Doug to see which systems are costing him the most money.  The report he pulls together is not exact, but will be good enough for planning purposes:

Later that week, Doug calls the team together to review the information that he and Lynn have gathered.  On the first pass, the team identifies the systems that are currently the most connected using Lynn’s information.  This highlights the “problem areas”:

On the second pass, the team uses Doug’s cost information to see where the budget is being spent the most.  In order to make a rounded decision, the team chooses to identify both the high cost maintenance systems as well as the systems that have a high cost for new development:

The final step of the analysis is to pull together the two views of the systems and rank, in order, the systems that need to be fixed.  This is much like creating a feature backlog, except that in this case we are creating a backlog of systems that need to be re-architected to deliver better revenue on investment.   At this stage the team is looking to identify the quick wins.  Using both the high interdependencies and high costs, Doug and the team identify the following list of systems as having the most benefit to re-architect:

1. eCommerce Website
2. Order Management
3. ERP
4. CRM
5. Identity Sync

Making the Plan

Having analyzed where the team needs to make their changes, it is time to move on to the planning phase.  There are 3 components to the Plan:

1. How?  This is where we do our solutioning for how to reduce costs.
2. When?  After we know how we will solve the problem, we need to figure out a timeline.
3. Who? Resource planning needs to be part of the discussion, and it may be identified that an external contractor might be required if the right resource isn’t in-house.

How do we solve this?

Lynn and some of the back-end development team have long been arguing that the reason for most of the costs is the tight coupling between systems and the copy/paste mentality that has caused maintenance to become incredibly difficult.  The analysis of the systems and the costs seems to support this anecdotal evidence in most cases.  Lynn is advocating an SOA approach in order to reduce the coupling between the systems and allow for easier maintenance of the business logic.

Some of the website team isn’t quite sure about that being the largest problem.  A few of the developers spend the majority of their time dealing with typos on the website, adding images to pages, and making other trivial edits to maintain the very large website.  These team members believe that distributing the content changes to marketing and allowing the website team to focus on more valuable tasks would solve some of their cost issues on the website side, whether or not an SOA approach is taken.  Doug’s numbers support this claim as he has a significant portion of his budget reserved for development staff to support content changes on the website.

When one of the team members suggests implementing a Content Management System (CMS) to allow the marketing team to edit the website, a question comes up about how they would get the marketing team to get access.  This triggers a solution discussion on authentication.  Most of the systems have their own authentication mechanisms, and the IT folks are finding that identity management is a huge pain.  They receive a lot of calls from customers trying to figure out which password and username are used for different systems.  Doug reviews his numbers, but doesn’t see any supporting costs in his analysis of this.  The IT team explains that this is because the costs are distributed between customer support and the IT support of multiple systems.  No single system has a huge cost for this, but together they add up.  The IT team suggests implementing a Single Sign-On (SSO) solution to simplify identity management for the users and for the IT team.

Doug is not convinced that moving to an SSO solution will provide enough of a cost reduction, but decides to run the idea by the business stakeholders to see if this is a feature that their customers would want.  Even if costs aren’t reduced, perhaps if the functionality can be sold as a revenue-generating item, Doug can make his IT team happier and improve the revenue-generation numbers.

When do we start?

Doug understands that this will take multiple years to accomplish.  Putting together a rough sequence events as a group, the team arrives at the following structure:

Given that there are other projects that need to be done, this will have to be done in parallel, or as part of, other projects.  By iterating through the solution, the team can achieve some immediate gains which will lead to the target architecture without needing to do a very long big-bang project.

Past the immediate timeline, there are also the other systems in play that need to be brought in.  Realistically, those elements are too far out to plan accurately right now.  The immediate plan for the next few years needs to be focused on the quick wins, and then as time moves along the other systems can be brought into a revised plan.

Who can get this done?

Doug’s team does not spend a lot of their day sitting around waiting to do something.  If anything, they have too much to do as it is, which is one of the reasons they are hoping to get this project done.  So how do they fit this extra work on their load?  I recommend one of the two options:

1. Tiger Team:  Select a handful of the best from the team and lock them down to this project.  They are untouchables.  Messaging goes out to the organization that some normal IT projects may be delayed or take longer since this group will no longer be available to help with them.
2. Outside Help: Grow the size of your team temporarily for targeted usage.  Either transition support activities to an outside organization to free up your own team or bring in consultants to focus on specific elements of your plan, with occasional support from your own team.

How long will this step take?

This will depend on the team, but the analysis portion will definitely be the largest variable.  Depending on how readily available information is, and what type of documentation is already available, it could take from a few days to several weeks to pull together the systems and budget spend information.

The planning should be scheduled across three days, with a maximum of 4 hours per session.  The first session should focus on going through the data pulled together on the system dependencies and budget spends.  The rest of the time will be focused on the planning.

How much will this step cost?

The cost gathering of the data is variable to the length of time it will take to gather the data.   The budget for this should allow for a few weeks for two senior individuals to work on gathering the information.  That should cover most scenarios.

The team analysis and planning sessions will be very expensive meetings. Your budget should plan for 12 hours of sessions with the senior team, along with any other major stakeholders.  If C-level stakeholders need to be involved in review, the time with those individuals should also be accounted for in the budget.  Try to limit this to about 4 hours in total for review and revisions.

What’s next?

This series continues with the team putting the plan into action, and building a way to measure their success.