Read an Excerpt
Chapter 10: Technology: Design & Hardware
The Third Rule - 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, but in our experience, unless there is a simple and clear architecture document, and every supervisor and program developer has a copy, the opportunity for missed communication with attendant misunderstandings and ill feelings, is far too great.
The Fourth Rule - Collective action
No one within the IS 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 is also a critical value that is essential to architectural success. If the staff of an IS organization do not have a sense of engagement and understanding of the benefits of collective action to serve customers, the organization will not be successful long term.
IS is a team sport, and cowboys need to understand the rules by which the organization functions. An IS organization with a strong architecture is better able to accommodate the cowboys and entrepreneurs, because it is able to clearly articulate the boundary conditions on all activities.
Simplify your network architecture as much as possible before deployment
We regularly see IS departments that have not moved to a single network protocol and are trying to support multiple protocols. One company we recently visited had TCP/IP, DecNet, AppleTalk, IPX, and SNA, running over Ethernet, Token Ring, FDDI, and ATM. And they complained their networks were unreliable and expensive to maintain.
Simplify down to TCP/IP, put IP stacks in your machines as you upgrade them and get rid of the older proprietary protocols. IP is even available for older mainframes, so there is no excuse for excessive complexity in your networks.
Treat architecture as a Lego set - examine the building blocks of your systems carefully
The architectural Holy Grail is to have systems that can be built like Lego blocks - each element can be replaced without affecting the whole design. This is not easy to achieve in practice, but don't give up. If your systems support standard protocols and provide APIs, you can glue the blocks together in ways that can more easily be torn apart.
Get good at glue
To follow our credo of open architecture, your development department will change its function. Instead of writing applications from scratch, they will be working to assemble functions from component parts. As a result, your development team needs to be schooled on protocols, writing and writing to APIs, and object technology.
The trends are clear. In the 1970s programmers in demand were those who were literate in 3GLs and managed file-based data systems. In the 1980s it was relational technology and PC systems. In the 1990s it is client/server. In 2000 it will be glue, objects, and Java. Make sure your people are ready.
One application per server vs. many on one
How many applications can I put on my new mainframe like server? Is it better to put one application per server? Can I shove as many applications as I can on my new server just like I used to do on my mainframe aren't they just as powerful today as those large mainframes are besides fewer boxes are easier and more cost efficient to maintain right-less floor space?
It would be more cost-efficient to treat these giant servers as mainframes, but we do not recommend it. Put one application on one box. Size the application to a box for flexibility!
Isn't it harder to manage more servers? No, if the processes and system management tools are implemented properly to manage to a more "lights-out" type of environment it shouldn't matter how many servers you support. The only drawback of course is back to the cost for data center floor space and licensing for those system management tools. But again customer productivity and satisfaction comes first.
Data warehouses are a service not an architecture
For many companies, data warehouses are a bug not a feature. We see IS departments claim data warehouses are needed to provide new and better services to their internal customers. Often, however, these warehouses compensate for the inflexibility and lack of information access in legacy systems. We understand the technical issues in warehouses, and we don't disagree with the need for such systems. Just don't use them as architectural Bondo to fill in the holes in an architecture that is in need of an overhaul. If you are considering the long-term implications of a warehouse system, hold it to the same architectural standards as other new system decisions. Warehouses grow (often quickly) and must be maintained like any other system.
Regulate architecture through an internal economy (if you can't twist arms)
In Charge back on page 78, we outline the importance and management of charge back. Empowering users and managing the flow of services through user fees is extremely important. The architectural benefits are more subtle but equally important. An effective architecture can be put in place by assigning fees in ways that encourage openness, standardization, and simplicity. Allowing users choices and charging for the differential cost is greatly preferable to imposing standards and then fighting with users to keep them from going off on their own. If you have a chargeback system consider using it to reward preferred behavior, such as using preferred tools or applications, rather than having to impose mandates on customers.
Build your applications architecture from a service-based foundation
Services come first, not applications. IS departments who let their architecture be dictated by any particular application are vulnerable to falling prey to vendor bias and proprietary traps that may be expensive to change later. This kind of application-centric focus is like selecting a house based on the interior furnishings rather than the number of rooms or its structural integrity.
For example, we talked with a CIO recently who was not happy with the cost of his desktop infrastructure and was looking for ways to defer an expensive upgrade. However, during our discussion, he said that he had to run Microsoft Office natively on his desktops, which meant that he had to upgrade his OS to Windows 95 which meant that he had to buy new Pentiums, which meant he had to ask for the large budget increase he knew his CEO wouldn't support. We suggested that he either reconsider his system requirements or look for a new job, since he clearly had painted himself into a corner.
Notice he violated two rules - his choices were not open, and his architecture was not standards based. He fell into the IS trap of the killer app with customers demanding "get me a box to run this application." That may make your customers happy in the short run, but when the customers turn fickle and want the "next big thing" what will you do?
Build around open standards
We are shameless advocates of open standards, although we freely admit that there are many happy ClOs who have given themselves to single-vendor, closed standards. Proprietary standards are often appealing because they are embedded in the products and do not require customer attention. Monogamous customers won't be happy at all if their vendor has troubles, or if they have to change their systems ot integrate third party software....