myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitect"Reference model" is a term that gets used loosely. Consultants call their frameworks reference models. Vendors call their product templates reference models. Some of these actually are. Many are not. This chapter draws the line. You will learn the taxonomy (model, reference model, reference architecture), the architectural strategies that make reference models useful for managing complexity, and the structure of the HERM suite that will serve as your worked example for the rest of the course. By the end, you will be able to look at any organizational artifact and say with confidence whether it qualifies and why.
By the end of this chapter, you'll be able to:
In Chapter 1, you learned why organizations need a common language. You saw the reinvention tax, the Chasm of Miscommunication, and the six objectives that reference models serve. You understand the problem.
Now we need precision. "Reference model" is a term that gets used loosely. Consultants call their frameworks reference models. Vendors call their product templates reference models. Departments call their internal process documents reference models. Some of these actually are reference models. Many are not. If we are going to build a course around this concept, we need to draw clear lines.
This chapter does three things. First, it defines the taxonomy: the difference between a model, a reference model, and a reference architecture. Second, it explains the architectural strategies that make reference models useful for managing complexity. Third, it introduces the HERM suite in structural detail, so you have a concrete example to carry through the rest of the course.
By the end of this chapter, you will be able to look at any organizational artifact and say with confidence: "That is a reference model" or "That is not a reference model, and here is why."
Create a free account to access Building the Common Language and start learning.