| Tweet |
|
|
Here’s a zipped pdf of the new 3.0 version of the Zachman Framework (with permission): ZF3.0.zip [approx 1.5M]. An official version will be posted on http://www.zachman.com soon. Visit Zachman’s new website for the latest!
Our Editor for BRCommunity.com, Keri Anderson Healy, attended the announcement event – she reports an excellent turnout. The following are some quick first-look notes from Keri (my own comments appear in brackets).
- The Framework has a new subtitle: The Enterprise Ontology (TM). Zachman considered changing the main title word “Framework” to “Ontology” but decided to stay with the former.
[Keri and I both think that was a good decision.]
- Some new terms appear as replacements, aiming to better convey the ‘business’ message. Zachman explains:
“Because I came from an ‘information’ community I had initially used words like ‘data’ in column 1. Big mistake! People thought the Framework was about IT! The first thing people saw was the word ‘data’.
[The Framework has always been about business engineering – that was clear even from the earliest talks I heard Zachman give in the late 1980s and early 1990s. In truth, I would have never guessed it would still be an issue 20+ years later.]
- Faint grey lines now appear crossing column boundaries in a row. These new connections better convey that the Framework supports two kinds of models: engineering (the primitives) and manufacturing (the composites).
The Framework is well-known for its depiction of the engineering primitives (the columns, which are normalized – one thing in one place). The engineering models, however, don’t do anything in and of themselves. The enterprise also needs its manufacturing models – the composites. So these new faint gray lines have been added as a reminder that the composite models also exist and they are also important.
Note: These new faint gray lines are meant as ‘for example’ connections. In this sense they are like the examples shown in the Framework for the primitives in the columns.
- Adjustments have been made to row 6 to better convey what it is about. In early versions of the Framework graphic, row 6 was depicted as just a sliver. It has always been ‘the enterprise’. Row 6 is different in nature from the five rows above it, which are engineering specifications for things in the enterprise, rather than the actual things themselves
- The rows are now color-coded and each cell icon reflects the color theme of its row. At the request of various Framework users, however, the background coloring has been removed from the cells of rows 1-5 so users can annotate their own specifics over the cell graphics.
- For rows 1-5, the color progression is red, orange, yellow, green, blue. Rather than the next-in-series indigo, row 6 is color-coded orange emphasizing that it represents the realization of what row 2 specifies.
[The row 2 / row 6 alignment is consistent with the business-engineering theme that Zachman so ably promotes.]
| Tweet |
|
|
{ 10 comments… read them below or add one }
Ron -
Interesting that John puts “inventory” on Column 1… in an industry that doesn’t keep a current inventory of its work product.
Personally I’m NOT for “ontology”… it’s become a tremendously over exposed term… sort of like putting the obligatory “Ummm” in a conversation.
David, You said:
Interesting that John puts “inventory” on Column 1… in an industry that doesn’t keep a current inventory of its work product.
>>Still a craft, not a profession?
Personally I’m NOT for “ontology”… it’s become a tremendously over exposed term… sort of like putting the obligatory “Ummm” in a conversation.
>>Business people are not too likely to relate to the term. And logicians and others who are into such matters have very stringent tests for such things.
I think John’s point, however, is that once you have a structured vocabulary you can ‘reason’ over it. I think that’s very likely to prove crucial for EA management and design tools of the future. Or maybe they’re already out there and I don’t know??
Concept systems are very fundamental to managing *any* kind of know-how. Businesses need an inventory of their concepts … literally. Sound arcane? Not at all. I’m just talking about structured business vocabularies. We are already in a knowledge economy … we just aren’t acting like it.
The Zachman Framework has been evolving over the last 20 some years. It has been, and will continue to be critical to our thinking in the field of enterprise architecture and business architecture.
The Zachman Framework for Enterprise Architecture is less of a framework because it does not define work products or artifacts as most other architecture frameworks do. Its strength is that it provides a great way of thinking about an enterprise (or a business) from different perspectives or viewpoints.
Since its first publication in the IBM Systems Journal in 1987, the Zachman Framework has become a major influence to many other later architecture frameworks or methodologies including OMG’s Model Driven Architecture, TOGAF, FEAF, The 4+1 View Model of Software Architecture etc.
The Zachman Framework was a pioneer of IT architectural framework. Zachman stressed that an information system does not have a single architecture, instead it has multiple diagrams and blueprints representing different aspects or viewpoints of the system just like a building architecture. This holistic thinking towards IT architecture (and business architecture) is the foundation of filling the long-debated gap between business and IT and making IT a true partner and asset to the business instead of a cost centre.
@Joanne – All very well said. The Framework is essentially a thinking tool. One of its great strengths (which a great many people miss) is that it is completely methodology-independent — intentionally. It’s just architecture, pure and simple. That’s why it will endure.
The changes in ZFv3 seem to be minor but important. Inclusion of lines (horizontal integration) across the columns is a good move.
I look forward to reading the ZFv3 concise definition of ‘inventory’ in the What column; and expect that there will be some debate regarding the apparent ‘absence of data’ as it is no longer specifically mentioned in the column heading.
It’s worth noting that even though the ‘What’ column may have been ‘labeled’ data at various times, it was always intended to be anything and everything of interest to the organization. In an earlier version of the concise definitions for “List of Things Important to the Business” Zachman included Products, Markets, Tornadoes as examples.
Beyond that I think ZF “will always be relevant to our thinking in the field of enterprise architecture and business architecture”.
The challenge enterprise architecture (rows 1-3), business architecture (rows 1-2), and IT architecture (row 3) face is operationalizing the framework in practice and in development of effective EA and BA methodologies.
@JD B. – You said:
>> “[I] expect that there will be some debate regarding the apparent ‘absence of data’ as it is no longer specifically mentioned in the column heading.”
RGR: It’surprising how subtle, yet crucial little changes like that can really be. I agree with the change entirely. A business is not in business to manange data; it’s in business to manage real-world things. (An insurance policy or financial product is very real to customers.) The business focus should be on what is our inventory of real-world things we need to manage. Data is simply how you represent what you know about real-world things in a system. Most people in our industry don’t get that.
>> “Beyond that I think Joanne was spot on when she said ZF “will always be relevant to our thinking in the field of enterprise architecture and business architecture”.”
RGR: I think it’s likely professionals will still be talking about the Zachman Framework 50 years from now. **I would encourage everyone who thinks the Framework is valuable to urge John to write and publish the definitive book.**
One type of artifact that I have found difficult to put into the right cell(s) in the ZF is specifications of system requirements, for example use case specifications and non-funtional requirements. To which cells do these artificts belong in ZF 3.0? Thank you for any hint.
@Jan – Re uses cases: With respect to Zachman and assuming you mean the traditional definition of use cases (see Wikipedia), I would put them in column 4 (“who”), row 3 (Architect Perspective). Developing uses cases involves designing man-machine interactions … which represent an architected way to support interacton ‘at a distance and over time’ between roles via composed work products.
I would have to defer on non-functional requirements … Haven’t really thought about it.
Thank you for your quick response.
Putting the use case specifications in the Who-column, Architecture Perspective row sounds reasonable if you consider the primary question answered by use cases is “Who (which roles/actors) are using/interacting with the system?”. However, the use cases also, and maybe foremost, answer the question “What kind of functionality is provided/realized by the system?” From that perspective, perhaps an alternative would be to place them in the How-column, Architecture Perspective row. After all, the process/work-flow definitions go into the How-column, row 2 (right?) and each use cases should be connected to the process activities/context where it is used. This way, functionality at both enterprise and system-level go into the same column (How).
@Jan — The generic models Zachman gives are:
* Column 4 (who): role-workproduct-role
* Column 2 (how): input-process-output or input-transform-output
To my mind, use cases are about creating some work product that some other role(s) need or can use. The flow or sequence you see is simply one deemed most effective for the ‘build’ of the work product.
{ 1 trackback }