Every so often I run in to an executive, change agent or disruptive thinker who is transforming the way technology delivers value to the business.  On one such recent meeting, I was asked a question that really made me dig deep in to my lessons learned from the past.  The question: “How do you create a shared service that is broad enough to provide value to an eclectic use base within an enterprise but not so generic that it becomes shelf ware?”

Let me start by telling you a story.

While engaged with a large financial services company, we ran in to an interesting challenge.  When looking at performance optimization for a key customer facing web application, we saw a call to their back end messaging infrastructure (custom built on a commercial message queue provider.  This call posted a small message and retrieved it immediately.  The message had no purpose other than that.  It did not affect the transactional state of the system in any way other than adding additional latency to an existing transaction.

Digging deep in to the mystery, we found that this was an attempt by the engineering team to “use” a mandated backend infrastructure.  The infrastructure did not support their requirements and was not easily customizable.  This was the team’s attempt at meeting architectural compliance and “slipping through the code review robots” while continuing to use their preferred JMS integration methods.  Their way of dealing with (or should we say working around) shelf ware.

The backend messaging infrastructure had become so generic, that it was literally useless, unable to be customized, had long development cycles and was causing huge delays.  The only reason for its adoption was through various mandates and governance mechanisms that the enterprise had in place.

How do you build a shared service that is not overly generic and bloated?

In this post, I will list 9 ways to ensure that you can create a shared service that is sufficiently flexible and nimble.  In future posts, I will elaborate on key steps to dive deep with examples and best practices.   I would love to hear your thoughts on this topic, be sure to share what has worked for you by clicking the “Talk to Us” below.  I will make sure I add those to this list as well.

9 Steps to Success

Here is a 9 step process to balancing generic design in shared services

1. Create Guard Rails: Start with the vison, goals and principles for the product or platform. This is the value system for making decisions.  If there is only one step that you want to implement, I would suggest this one. Guard rails must be “blessed” by executive stakeholders and product consumers alike.
2. Over Communicate, Be Inclusive: As the champion of the shared service, your job is to communicate the vision for the service and the key performance indicators. Share the vision, goals and principles and create and maintain an agile roadmap and backlog. Involve all stakeholders in backlog grooming during the program increment planning process
3. Always start with an MVP: Be religious about building a minimally viable product (the core), only the absolute minimal functional requirements. Improve MVP incrementally with bi-weekly enhancements. Be selective about what makes the cut.
4. Design for Extendibility: Build core libraries that are immutable, but allow for add-on components that can extend the product.
5. Take an Open Source Perspective: Allow business area teams (scrum teams) to contribute to the product by developing extensions and add-ons. (think Eclipse)
6. Create a Marketplace with Bragging Rights: Provide a place for users of the product to share add-ons with others (think Splunkbase)
7. Apply the “Generic” Pressure Test: Only make a solution or add-on generic (include it in the core) if it has stood the test of time passed the test of demand . It is stable for more than a release and sought after by more than two teams.
8. Take an economic view for prioritization: Be radically transparent about the process for a feature making the cut.  Ask teams to quantify metrics such as cycle time, value, product cost and risk when requesting for features.
9. Plan for Exceptions: Design a waiver process that allows for workarounds to meet business needs. Obtain senior management commitment to address waivers in reasonable time.

How can Terafuze help?

Our Enterprise Architecture Blueprints are battle hardened and contain a step by step guide to incrementally enabling components for reuse.  Our unique methodology looks beyond technology and provides actionable insight on creating, refactoring or scaling shared services at the enterprise level.  Applying startup thinking at enterprise scale, we take a holistic view that includes technology, engineering, operations and organization to creating a successful shared service strategy. Are you ready make your shared services world class?[/vc_column_text][/vc_column][/vc_row]