Around five years ago, I remember a lot of folks started getting into the hype around Service-Oriented Architecture. “This is the way of the future!” you would hear, or “All of our problems will be solved by moving to SaaS or SOA!” Take a moment now and consider your own workplace. How much of your business processes are actually sitting in a nice reusable service? Any?  Alternatively, how many times have you had to make a bug fix in the middle of a bunch of hard-coded integration logic running SQL directly to a legacy system?

There’s probably one eager developer at your workplace (maybe even you?) that jumped on the bandwagon, built an ASMX or WCF service to serve up tombstone data from a legacy backend, and then gave up when nobody else adopted it. Adoption has been a huge problem in many organizations, especially small-to-medium businesses that simply don’t have the budgets to rebuild their entire infrastructure from the current spaghetti mess of interdependencies to a full SOA managed by an Enterprise Service Bus.

These days, I work with a lot of clients that are trying to better distribute their business processes by moving towards using a content migration system like Sitecore. The primary problems these businesses have is that reliance on the IT team for managing the marketing content of the website just doesn’t allow the content owners to manage their website with the speed they need to beat the market. However, dropping a CMS into the mix only further complicates the architecture for these IT teams. The website still needs all of the special connections to integrated systems that were there previously, but now need to work with a CMS as well. On top of that, as excitement builds around a new website, others want to get on the gravy train as well and take advantage of everything being done for the primary marketing asset.

Why SOA?

So why should an organization move towards a service-oriented architecture?  In fact, in a lot of organizations, they probably shouldn’t.  If the team can’t, or won’t, be able to implement it properly, the effort might actually hurt costs in the division.  Additionally, without proper governance in place, releasing new services into the ecosystem can lead to even more problems than the team is already facing.  The goal, however, is to do it right: decrease maintenance costs, decouple systems, increase re-usability of business logic, and increase ability to react to the market.

So how do we move from a hugely interdependent mess of hard-coded integrations towards a full-blown SOA to allow us to share that wealth and maintain it efficiently? What is our strategy to go from where we are now, to where we need to be? In the next few articles, I’m going to take you on the baby steps your team can take to evolve your digital asset architecture. You can then use this as the base for your technical roadmap for gradually improving your ability to maintain and enhance your digital assets.

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

The Scenario

During this series, we will follow a sample IT team managing the digital assets at a fictional 500-employee company that runs the modestly successful BuyMyWidget.com. The marketing team has contacted Doug, our fictional CIO, to find out if they can start managing the website content themselves. Doug has made some inquiries and feels confident he might be able to delay this need for a year or so, but any longer than that “won’t be acceptable”.

At the same time, Doug’s budget costs from the previous year are under scrutiny. His team is unable to deliver new revenue-generating features without significant costs, and most of his team are unavailable due to incredibly time-consuming ongoing maintenance and support needs. The board hasn’t cut Doug’s budget yet, but has indicated that Doug needs to show better revenue coming from his team’s activities in order for them to justify the costs.

To complicate matters, Doug has just heard that the customer relationship-management application the company uses is reaching end-of-life in four years and they will need to update to the latest version. The new version has a massively altered data model, but provides a modest API to help with custom integration needs. Aside from licensing costs, his team is going to have to completely rebuild their integration logic.

As if that weren’t enough to deal with this week, a recent viral marketing campaign has increased traffic to the primary ecommerce website well beyond anything the team has seen before. Customers are complaining about slow load-times and dropped order transactions. Dealing with this is going to consume a lot of the team on an ongoing basis, which means there is no time to just stop everything and execute the other projects immediately.

Doug’s chief architect, Lynn, has explained that a lot of their costs in maintenance are due to legacy code written years ago by a developer no longer with the company. It is hard to find where problems are, and very expensive to fix them. Since the team has only been hacking in fixes and new features on top of a bad base, the system has gradually become a huge cost sink-hole. Lynn wants to start from scratch and build it out “the right way” so that they can stop having these problems. The entire team is behind this idea, and is very eager to try to build something better rather than the daily grind they are experiencing now. Doug is unsure that he can handle a new R&D project along with all of the other projects, but knows that turnover rate of employees in the development team has been higher recently due to the nature of the work they are having to do. Increasing retention will decrease Doug’s costs, so Doug and Lynn decide to figure out a plan.

What’s next?

This series continues with Doug, Lynn, and the rest of the team sitting down to analyze what they have and put together a plan of attack as they follow the first step of the roadmap.