- Introduction
- Focus on the Big Rules
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Focus on the Big Rules
Architectural principles must flow from the top to the bottom; that is, from the high-level principles down to the fine-grained detail of how the elements of the IT systems interact. Too often, IT organizations try to agree on the lower-level specifications and protocols ("We'll use xyz") before management has agreed on the "Big Rules." What are the Big Rules? They're the basic agreements by which people in the organization can work out their issues and differences relative to the architecture.
Rule #1: Consensus
If an architecture is to be followed, there must be trust between all those who live within the architectural framework. If there is to be trust, then there should be no surprises—that's the first Big Rule. No surprises means that within the IT organization, preferential access to information cannot be used as a means of control. How often have you walked into a meeting to be surprised by a change of direction or some new piece of information that hasn't been shared? Following the no-surprises philosophy, all information should be shared with those affected by the information, and if a decision must be made, there must be an active solicitation of opinion and individuals must be given adequate time to respond. To do otherwise is to break down the trust level between the parties. Mistrust is a powerful incentive for people to go off and "do their own thing" by building shadow systems or otherwise breaking the architecture.
Rule #2: Consistency
No one is allowed to break the architecture. Waivers can be granted if needed, but everyone must agree in advance that the architecture cannot be ignored. If this rule is not enforced, chaos will result. At the same time, of course, there must be an appeal mechanism. Architecture is not a club to be used by one IT activity against another, so senior management must be sensitive to user concerns and respond appropriately.
Rule #3: Create a Written History
The third big rule is that the architecture must be written down, and those affected must have input into it. Oral architectures are a tradition in some organizations. In my experience, however, unless there is a simple and clear architecture document and every supervisor and program developer has a copy, the opportunity is far too great for missed communication (with attendant misunderstandings and ill feelings).
Rule #4: Collective Action
No one within the IT organization is allowed to say "not my job." Everyone must participate and no one can abrogate his or her responsibility to the success of the enterprise by passing the buck to someone else. This is a statement of esprit de corps and individual responsibility, but it's also a critical value that's essential to architecture success. If the staff of an IT organization doesn't have a sense of engagement and understanding of the benefits of collective action to serve customers, the organization will not be successful long-term.
IT is a team sport, and cowboys need to understand the rules by which the organization functions. An IT organization with a strong architecture is better able to accommodate the cowboys and entrepreneurs, because it's able to clearly articulate the boundary conditions on all activities.