Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.



One of the main reasons why I blog is to share my experiences with other Enterprise Architects so we can learn from each other. Today, I am not going to share a success story but instead will describe some decisions we made early on that we would probably do differently now that we know more.

The scenario:

After we sold the business on BPM and SOA, we were challenged to implement a pilot project quickly to show the value of SOA. It was critical that we deliver early and often as opposed to going off for 8-12 months without giving the business any relief from its legacy business processes. To meet this objective we established a 12 week "pilot" or "beta" project that started as soon as we purchased our SOA stack. This did not give us time to implement governance. We agreed that during the second wave of projects we would implement governance as part of those projects. As we started the second wave of projects, I mandated that all code should be delivered with test harnesses, the build process should be 100% automated, and testing automation should be part of the project deliverables.

Those all seemed like reasonable objectives, so what could go wrong with that plan?

The Reality:

A few things happened along the way that caused the initial pilot project to extend longer then anticipated. First of all, getting all of the individual pieces of the stack (portal, BPM, ESB, and data services) to work properly together took way longer then any of us ever dreamed of. Luckily the vendor understood the urgency of our issues and dedicated many resources to help resolve our issues but this cost us several weeks. Guess what? Now we are mitigating our risks for getting the next six concurrent SOA projects delivered by the end of the year. What do you think is the only thing left to cut out? That's right, governance, build automation, and testing automation.

Lesson Learned:

Don't take any short cuts when it comes to governance and automation. We will eventually get there but it will be much harder to implement this stuff at a later date then it would have been before we moved to production. I am also fearful that we might continue to prolong or delay governance and automation to hit various dates along the way. We can get by today, but several months from now when we have over a hundred services and a dozen projects in production, we better have this resolved or we will be working hard instead of working smart.

Recommendations:

Here are a couple of things I would do differently next time. Staff the governance and automation initiatives with dedicated individuals who are not tied to other deliverables. I would also define and manage these initiatives as individual projects with published milestones and get executive buy in to ensure that these deliverables get the focus they need.

Hopefully this has been helpful for those of you who are considering SOA or are early on in the process. I would love to hear your experiences and/or your recommendations going forward.

2 comments

  1. Todd Biske  

    Mike-

    Thanks for sharing your experiences. One interesting thing I saw was that you included test first development and automated tests and builds in your scope. I've run into other organizations that have used SOA to try to fix all things about the development process, many that really are completely independent of SOA. It is unfortunate that this has to happen. It is very similar to the federal legislative process where so many things need to be added to a bill, simply because they're too small to garner enough attention on their own. These small things can then put the core at risk.

  2. Mike Kavis  

    @biske,

    Thanks for the feedback. One of the reasons for the test first development is that I don't have an abundance of resources to support these initiatives. I have to build a support team over time which involves getting the business to agree to stop working on other projects to free up resources. Until then I need as much automation as possible to limit the number of people required to test.

Post a Comment



Subscribe to: Post Comments (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"