Putting Enterprise Architecture Principles to Work
January 9, 2015 Leave a comment
This week brought another great consulting gig, working with old friends and respected colleagues. The challenge driving the consultation was brainstorming a new service for their company, and how best to get it into operation.
The new service vision was pretty good. The service would fill a hole, or shortfall in the industry which would better enable their customers to compete in markets both in the US and abroad. However the process of planning and delivering this service, well, simply did not exist.
The team’s sense of urgency to deliver the service was high, based on a perception if they did not move quickly, then they would suffer an opportunity loss while competitors moved quickly to fill the service need themselves.
While it may have been easy to “jump on the bandwagon” and share the team’s enthusiasm, they lacked several critical components of delivering a new service, which included:
- No specific product or service definition
- No, even high level, market analysis or survey
- No cost analysis or revenue projection
- No risk analysis
- No high level implementation plan or schedule
“We have great ideas from vendors, and are going to try and put together a quick pilot test as quickly as possible. We are trying to gather a few of our customers to participate right now” stated one of the team.
At that point, reluctantly, I had to put on the brakes. While not making any attempt to dampen the team’s enthusiasm, to promote a successful service launch I forced them to consider additional requirements, such as:
- The need to build a business case
- The need for integration of the service into existing back office systems, such as inventory, book-to-bank, OSS, management and monitoring, finance and billing, executive dashboards (KPIs, service performance, etc.)
- Staffing and training requirements
- Options of in-sourcing, outsourcing, or partnering to deliver the service
- Developing RFPs (even simple RFPs) to help evaluate vendor options
- and a few other major items
“That just sounds like too much work. If we need to go through all that, we’ll never deliver the service. Better to just work with a couple vendors and get it on the street.”
I should note the service would touch many, many people in the target industry, which is very tech-centric. Success or failure of the service could have a major impact on the success or failure of many in the industry.
Being a card-carrying member of the enterprise architecture cult, and a proponent of other IT-related frameworks such as ITIL, COBIT, Open FAIR, and other business modeling, there are certainly bound to be conflicts between following a very structured approach to building business services, and the need for agile creativity and innovation.
In this case, asking the team to indulge me for a few minutes while I mapped out a simple, structured approach to developing and delivering the envisioned service. By using simplified version of the TOGAF Architecture Development Method (ADM), and adding a few lines related to standards and service development methodology, such as the vision –> AS-IS –> gap analysis –> solutions development model, it did not take long for the team to reconsider their aggressive approach.
When preparing a chart of timelines using the “TOGAF Light,” or EA framework, the timelines were oddly similar to the aggressive approach. The main difference being at the end of the EA approach the service not only followed a very logical, disciplined, measurable, governable, and flexible service.
Sounds a bit utopian, but in reality we were able to get to the service delivery with a better product, without sacrificing any innovation, agility, or market urgency.
This is the future of IT. As we continue to move away from the frenzy of service deliveries of the Internet Age, and begin focusing on the business nature, including role IT plays in critical global infrastructures, the disciplines of following product and service development and delivery will continue to gain importance.