Using Business Capabilities
Once upon a time, there developed a technology company. Over the years this technology company grew and grew and as it grew it developed a long and impressive list of achievements, products, and unfortunately: a very large inflexible legacy system that evolved from technology rather than from business goals. This system is now in a place where it is hard to change, causes immense headaches, demands a lot of attention, and has a large financial impact on the company’s bottom line.
I often refer to this technology company as: “the Big ‘Ole Tanker.”
In the background are a few small nimble tech companies who entered the industry later, who were able learn from the mistakes of others and model their systems on a foundation new ideas and technology. Because of this they can change direction, focus, and add new technology with ease because they are not as tied to rigid legacy systems.
I call these companies the: “small nimble speedboats.”
How can this large tanker ship even compete with a nimble speed boat for new business in a rapidly changing industry? How can they add new product lines quickly without knocking down a stack of fragile legacy vendor systems tied together with bubble gum, duct tape, and splints when re-engineering the system is not a viable option?
Enter Service Oriented Architecture (SOA) and Business Capability Modeling (BCM) — with both focusing on what a business does rather than how a business does it to build a system that is adaptable, flexible, and business oriented.
Business Capability Modeling (BCM) is a means of determining your business architecture; it means building a structure that focuses on business goals (capabilities) rather than the technical processes that achieve these goals. In other words, focusing on those things that tend to remain constant in a business (the what: invoicing a customer, adding a customer, etc.) instead of how this is achieved (e.g. building a database structure that uses MySQL to generate invoices). This kind of thinking goes against the grain of most technology companies where the tech department is revered (or feared) and there is a disconnect between what the business thinks it is doing and what the tech department is actually creating. From this disconnect spawns mal-aligned systems, a language disconnect, and a whole schwack of headaches.
In starting with capability mapping, a business is able to determine where the important business capabilities are (course grained), decompose these into finer grained activities again and again until you have a well defined business architecture that can then be used to construct numerous “black boxes” that contain the technology, the processes, and all that technical goo that the business doesn’t really need to wrap their head around. Further to this, each box does NOT work in isolation but rather reaches out and communicates with other black boxes to make sure that larger business capabilities are being achieved.
In taking this back to the Big ‘Ole Tanker: what if we were to break up the ship into a bunch of boxes determined by capabilities, encapsulate each box in bubble wrap (Services), get them talking to each other via an intricate communications system, and then send the entire tanker off as an interconnected network unit that allows boxes to be removed and added as needed? Would it not be able to do the same as the fleet of small nimble ships — with better networking and interconnect-ability?
For now there’s a lot of debate out there on the “how tos and wither tos” of everything above. My main point is the same one that I’ve been blabbing about for a while: business first, technology second. After all, technology is a tool that allows businesses to achieve their goals… not the other way around.