It’s our responsibility as architects to make sure our work is implemented. We’ve been dealing a lot lately with questions about what makes a good architecture, what should be in an architecture, what’s the difference between a technical architecture and an information architecture, etc. But somewhere along the line we failed to emphasize perhaps one of the most important points in this business.

“It isn’t architecture until it’s built.” While that seems quite obvious when it’s stated, it’s the kind of observation that we almost need to have tattooed or at least put on our wall where we won’t forget it. It’s very easy to invest a great deal of time in elegant designs and even plans. But until and unless the architecture gets implemented it isn’t anything at all; it’s just a picture. What does get implemented has an architecture. It may not be very good architecture. It may not lend itself to easy modification or upgrade or any of the many virtues that we desire in our “architected” solutions. But it is architecture.

So the implication for architects is that we need to dedicate whatever percent of our time is necessary to ensure that the work gets implemented. It’s really very binary. You belong to an architectural group. Maybe you are the only architect, or maybe there are five people in your group. In either case, if your work product results in a change to the information architecture the benefits can be substantial. Almost any architectural group could be justified by a 10 or 20% improvement. Frankly, in most shops a 50 to 90% improvement in many areas is possible. So on the one side, if a new architecture gets adopted at all it’s very likely to have a high payback. But the flip side is that a new architecture, no matter how elegant, is not worth anything if it’s not implemented and the company would be acting rationally if it terminated all the architects.

The implication is that as architects we need to determine the optimal blend between designing the “best architecture” and investing our time in the various messy and political activities that ensure that an architecture will get implemented. These range from working through governance procedures to making sure that management is clear about a vision to continually returning to the cost-benefit advantages, etc. The specifics are many, and varied. In many organizations you may be lucky enough that you may not have to invest a great deal of your time to get a new architecture and implement it. Perhaps you’re fortunate enough to have insightful leadership or a culture that is eager to embrace a new architecture. If that’s the case, you might get away with spending 10 or 20% of your time ensuring that your architecture is getting implemented and spend the vast majority on developing, designing and enhancing the architecture itself.

However, if you’re like many organizations, life for the architect will not be that easy. You might find it profitable to spend nearly half your time in activities that are meant to promote the adoption of the architecture. Certainly you should never pass up an opportunity to make a presentation or help goad a developer along. Indeed, the importance is so great that given an opportunity to present you would do well to invest disproportionately in the quality of the presentation, as a perfunctory presentation about the status or a particular technical standard is not likely to move developers or management to adopt it and you may need to return to the theme over and over again.

As someone once pointed out to me, in matters such as this the optimal amount of communication is to over communicate. The rule is when you’re absolutely certain that you’ve communicated an idea so many times, so thoroughly, and so exhaustively that it just is not possible that anyone could tolerate hearing it any more, that’s probably just about right. Experience says that when we think we’ve communicated something thoroughly and repeatedly three-fourths of the audience has still not internalized the message. People are busy and messages bounce off them and need to be repeated over and over and over. And you’ll find that each part of your audience will accept and internalize a message in a different way from a different presentation and at different rates. I’m continually amazed when I get some feedback with a particular stakeholder at some meeting. The coins finally drop and they become advocates for some position we’d taken. In some cases I’ve gone back and realized that we’ve presented it many times to that person and somehow finally one time it took. In other cases we realized that, in fact, we hadn’t presented already it to that individual. We thought we’d covered everyone but they weren’t in certain meetings or we repeat something so many times we think everybody must have heard it and, in fact, that’s not the case at all.

In closing, I’d like to recommend that every architect make a little plaque and put it near their desk that says: “It isn’t architecture until it’s built.” That might help you decide what you are going to do tomorrow morning when you come into work.

Written by Dave McComb

Event-driven architecture as the latest buzzword in the enterprise architecture space.

Those of us in the complex sale sector need to be aware that volume operations from adjacent marketplaces will soon enter ours.

Shortly after you start your inquiry about software architecture, or enterprise architecture as it is often called, you will come across the Zachman Framework.

The Zachman Framework is a product of John Zachman who has been championing this cause for at least 15 years, first with IBM and then on his own. As with so many things in this domain, we have an opinion on the Zachman Framework and are more than willing to share it.

What Is the The Zachman Framework?

First though, let’s describe just what the Zachman Framework is. John Zachman believes, as we do, that software is a human created artifact of large-scale and as such we may learn a considerable amount from the analogy between software and other large-scale artifacts of human creation. In the early days of software development, there were many who felt that perhaps software was a creative activity more akin to writing or artistry or perhaps craftsmanship on a small-scale.

However, this idea has mostly faded as the scale and interconnectedness of the pieces has continued to increase. Some of John’s early writings compared software or enterprise architecture to the architectures needed to support airframe manufacturing, aircraft, rockets and the like. His observation was that in order to deal with the complexity of the problem in these domains, people have historically divided the problem into manageable pieces. The genius of John’s approach and his framework has been in the orthogonality of the dimensions of which he divided the framework.

The Zachman Framework is displayed as a matrix. However, John is careful to point out that it is not a “matrix” but a “schema” and should not be extended or modified, as in his belief it is complete in its depth and breadth.

The orthogonal dimensions referred to above are shown in rows and columns here. In the rows are the points of view of the various stakeholders of the project or the enterprise. So for instance, at the highest level is the architecture from the point of view of the owner of the project or the enterprise and as we transform the architecture through the succeeding rows we gradually get to a more and more refined scope, as would be typical of the people who need to implement the architecture or eventually the products of the architecture. In a similar way, the columns are orthogonal dimensions and in this case, John refers to them as the interrogatories So, each column is an answer to one of Rudyard Kipling’s six able servants: who, what, when, where, how, and why. Each column is a different take on the architecture, so for instance, the “what” column deals with information, the “things”about which the system is dealing.

In the aircraft analogy, it would be the materials and the parts. Likewise, the “how” column refers primarily to functions or processes; the “where” to the distribution of networking; the “when” to scheduling cycle times and workflow; the “who” to the people and organizations involved in each of the processes; and the “why” to strategy and eventually down to business rules.

Behind this framework then are models which allow you to describe an architecture or any artifact; a specific design of a part of a product or database table, or whatever, within the domain of that cell. Many people have the misperception that at the high-level there is less detail and that you add detail as you come down the rows. As John is very fond of pointing out, you need “excruciating” detail at every level and what is occurring at the transition from row to row is the addition of implementation constraints that make the thing buildable.

John has been a tireless champion of this cause, and from that standpoint we have him to thank for pointing out that this is an issue, and furthermore for championing it and keeping it in the forefront of discussion for a long, long period of time. He’s been instrumental in making sure that senior management understands the importance and the central role of enterprise architecture.

What the Zachman Framework Is Not

At this point though, we need to point out that the Zachman Framework is not an architecture. And the construction of models behind the framework is not, in and of itself, an architecture. It may be a way to describe an architecture, it may be a very handy way for gathering and organizing the input you need into an architectural definition project, but it is not an architecture nor is it a methodology for creating one. We believe the framework is an excellent vehicle for explaining, communicating, and understanding either a current architecture or a proposed architecture.

However, it is our belief that a software architecture, much like a building architecture or an urban plan, is a created and designed artifact that can only be described and modeled after it has been created and that the act of modeling it is not the act of creating it. So in closing, to reconcile our approach with the Zachman Framework we would say that firstly, we have a methodological approach to creating enterprise software architecture. Secondly, we have considerable experience in actually performing this and creating architectures that people have used to develop and implement systems. Thirdly, these architectures that we have designed/developed can be modeled, described, and communicated using the Zachman Framework. But that does not mean that they were, or in our opinion, even could be created through a methodological modeling process as suggested by the Zachman Framework.

“Action without planning is folly but planning without action is futile.”

In this write-up, we explore the intimate connection between architecture and planning. At first blush, they seem to be completely separate disciplines. On closer examination, they appear to be two sides of the same coin. But in the final examination, we find that they are intimately intertwined but still separate and potentially independent. The motivation for this paper was an observation that much of our work deals with system planning of some variety. And yet, there is virtually nothing on a web site on this topic.

On one level that may be excusable. There is nothing drastically new about our brand of planning that distinguishes it from planning as it has been practiced for decades. On the other hand, system architectures typically are new and evolving and there are new observations to be made. But there’s more to it than that. We have so baked planning into our architectural work that we no longer notice that it’s there. This paper is the beginning of an attempt to extricate the planning and describe it as a sub discipline of its own. Are architecture and planning the same thing? Can we have one without the other? This is where we begin our discussion.

Certainly, we can have planning without architecture. Any trivial planning is done without architecture. We can plan a trip to the store or a vacation without dealing with architecture. We can even do a great deal of business planning, even system planning, as long as the implicit assumption is that the new projects will continue using any existing architecture. So certainly, we can have planning without architecture. But can we have architecture without planning? Well, certainly it’s possible to do some architectural work without planning.

There are two major ways this can come to be. One is that we can allow developers to develop whatever architecture they want without subjecting it to a planning process. The end product of this is the ad hoc or accidental changes that so characterize the as built architectures we find. The other way, which is as common, is to allow an architectural group to define an architecture without requiring that they determine how we get from where we are to where we want to be. Someone once said, “Action without planning is folly but planning without action is futile.” The architect who does architectural work without doing any planning is really just participating in an exercise in futility.

An intentional architecture requires a desired “to be” state, where some aspect of software development, maintenance or operation is better than it currently is. There are many potential aspects to the better state in the “to be” architecture: it could be less risky, it could be more productive, it could scale better, it could be more flexible, it could be easier for end-users to use, it could be more consistent, etc.

What they all share is that it is not the same as what exists now and in order to migrate from the “as is” to the “to be” requires planning. In the nineties, we seemed able to get away with a much more simplistic view of planning. “Rip and replace” was the order of the day once you determined what the target architecture looked like. Most organizations now have far too much invested in their legacy systems to contemplate a “rip and replace” strategy to improve either their architectures or their applications. As a result, the onus is on the architects to determine incremental strategies for shifting the existing architecture to the desired one. The company must continue to run through the potentially long transition period.

The constraints of the many interim stages of the evolving architecture and applications create many challenges for the planner. In some ways, it’s much like the widening of the heavily trafficked highway: it would be quite simple to widen it, if we could merely get all this traffic off of it but given that we can’t, there is often an extremely elaborate series of detours that each has to be planned, implemented and executed. In conclusion, I think we can see that architecture desperately needs planning. Indeed, the two are inseparable. While planning can certainly live on in the absence of architecture, architecture will not make any meaningful progress in any established company without an extreme commitment to planning.

By Dave McComb