Early last year one of our first business-side clients from the 1990s called out of the blue. We last worked with them in 1998 helping first to create a Policy Charter (structured solution strategy) and future-form business process model for an entire line of business. Then we worked with them to create a Concept Model.
Quick aside: A Concept Model, also called a fact model, is akin to a conceptual data model except it directly models the business vocabulary used for core concepts rather than high-level business entities that are actually data-things-in-the-making. I wrote about the differences in the February 1, 2012 issue of TDAN (see http://www.tdan.com/view-articles/15838).
Back to the story: After our work with the client in the late 1990s we had since lost touch, so they brought us up to date. In 1998 and 1999 they built a completely new system (largely in an early version of Java) based on our work together. The system had supported world-wide business operations quite well until just recently. In the past year or two though, the business had expanded both in volume and variety, and the existing system architecture had simply maxed out.
A pleasant surprise awaited me when I went for an on-site visit a few days after the call. Sitting on the conference room table in front of the business managers was a large plot of the 1998 Concept Model! They said, “The Concept Model is still about 90% accurate. We’ve determined it’s really the only thing we can salvage from the legacy environment. It’s our business blueprint for a next generation of software.” Although lots had changed in their dynamic business space through the intervening years, the core know-how had remained 90% the same.
The 1998 Concept Model focused on a single line of business. Led by IT, their other major line of business unfortunately had opted not to use the relevant portions of the Concept Model or follow the approach. (They estimated about 60% overlap between the two lines of business.)
In the dozen years since, this other line of business abundantly demonstrated the business (and software) pitfalls of not having done so. Side-by-side comparisons of key business concepts highlighted the shortcomings.
Why had they called us back just now? Recently the organization had acquired a third line of business, also interrelated. Management understood they needed an integrated, holistic view of the business. Expanding the Concept Model to include the other two areas was the obvious path forward.
Your Concept Model is about the business and its core know-how, not IT. That’s why it will stand the test of time.
