(from a presentation from my KPMG Consulting days)
Hello. Pierre will be getting up here in a few moments to dive into our approach to IT Architectures and to some case studies based on work we’ve done as a firm. Before that, at a very high level, I want to spend 10 or 15 minutes addressing these three questions: What is an IT Architecture, Why Do You Want One, and Why Aren’t They More Common.
Two thousand years ago, Ecclesiastes told us “there is no new thing under the sun.” There are only a very few books on IT Architecture, and they draw on ancient concepts. Melissa Cook’s book uses Plato and Aristotle to explain IT Architectures, and Bernard Boar’s book explains technology strategies using Machiavelli’s “The Prince” and Sun Tzu’s “The Art of War.” I’ll use items from these two books to help answer our three questions.
To help answer the question “What is an IT Architecture?” let me use two analogies, house building and telephone systems.
The architecture of building a house is a good model for understanding in very broad terms what an IT Architecture is. Archimedes wrote the first known book on Architecture in 250 B.C., so it would seem that architecture is not a new thing under the sun. The key components of home architecture are to take the needs and wants of the homeowners and their budget and to take the available tools and techniques of the builder’s craft, and join these worlds of wants and capabilities into a cohesive plan of action, a blueprint.
And so this brings us to our first understanding of an IT Architecture: it is a plan of action, a blueprint, which seeks to satisfy the needs and wants of the business owners by using the available tools and techniques of the information age. Anything will fail if it does not have a plan. There’s a house in California which was built by a madwoman who had more money than foresight. The money came from Winchester guns, and the madness included her belief that she was being chased by the souls who had lost their lives due to the guns. So, the house has rooms and wings and hallways added on by the whim of the moment, to confuse the ghosts. There are staircases that go nowhere.
Compare that with your building. You have ample space, raised floors, enough electricity, etc. to the point where the building serves the needs of the organization. I’m sure that you have your complaints about this building nonetheless, but think how much worse it would be if it had been thrown together by independent workmen working without an architectural plan.
Let’s turn to something a little less obviously architectural: a telephone system. When Alexander Bell said “Watson, come here!”, there were two telephones in existence, and they were each connected to the other. Let us imagine that as phones were added to this nascent network, that they were each connected to the other. With three phones, there are thee connections, with four there are six connections. In fact, with this connection scheme there are (n2 – n)/2 connections for each n telephones (sorry to throw math at you so soon before the holidays!). This means with 500 telephones there would be 124,750 connections, and each phone would have 499 wires leading out of it.
This would clearly be an unacceptable situation, and the answer, with telephones at least, is plain enough to see. Let’s put a switch in the mix. Now, instead of connecting each phone to all of the others, we connect each phone to the switch. With 500 phones, we have 500 connections, not 124,750. Each phone needs to have one wire coming out, not 499. This should make phones much cheaper to build and install, and maintenance to a single switch replaces maintenance to 124,750 connections.
Note that the first time you put a switch in (or in software, what's called Middleware), the initial result is
more complexity!
But you know your blueprint, and so you have the courage that comes from knowing the final stage:
And you know this will scale. If you have 200 connections "wired" through your middleware, then adding another is only one more, and not the 19,900 that it would have been had everything been wired together to everything else - the "spaghetti" that IT people often talk about.
When Enterprise Architects show diagrams of the “ideal IT Architecture”, at first glance it looks as simple and inviting as the electrical wiring scheme for Chicago. So I’ll ask you to think back to the simple telephone switch example, because this example leads us to further our understanding of an IT Architecture. An IT Architecture tries to reduce complexity through the use of well-defined, standard interfaces, just like our telephone switch.
So if an IT Architecture is simply a plan of action which addresses the needs of the business, and this plan is based on building systems with standard, interoperable connections to a “master switch”, using principles which are thousands of years old, then we might jump ahead to our third question and ask “Why aren’t IT Architectures commonplace?”
Well, maybe Ecclesiastes was just a bit off with the comment that there is no new thing under the sun. Information science may have started back with Plato and Socrates, but the modern tools of this science are only 50 years old.
To understand the difficulty that new things have in yielding to architectural solutions, let’s look at the product lifecycle as put forth by Robert Brady in 1961.We see that new products are born out of pure scientific discovery, then they are refined through applied science, invention, industrial research, industrial applications, standardization and finally mass production. And as I’ve indicated on the graph, the need for and the ability to produce an architecture for a given product won’t arise until there are standards. And it is this lack of standards that is slowing down IT Architecture development.
Here’s a quick example: before the Civil War, train tracks in the North were a different width than train track in the South. There wasn’t a national standard. It wasn’t until the business barons of the day demanded standardization that the tracks were made consistent throughout the country. And during the transition, there was rioting by the people whose jobs it had been to unload and reload the cars where the incompatible tracks met.
This resistance to standards is natural, because standards represent a compromise that ultimately leaves everyone settling for something less than they want. Also, product developers use their non-standard approaches to differentiate their products from the competition. This is the position Microsoft is in today. They are resistant to open standards such as Java and network computing because these standards would threaten Microsoft’s dominance.
While the resistance to standards is natural, the importance of standards is undeniable. 70 city blocks of Baltimore burned down in 18?? Because outlying fire stations had different hose couplings than Baltimore city’s. Without standards, less dramatic but equally costly problems would arise everyday. Turn back to our house architecture example. Homes are built on an enormous number of standards, from the spacing of studs in the wall to the height of stairs and the thickness of lumber.
We are starting to see standards emerge in the IT world. Examples include programming languages such as C, C++, C# and Java, networking protocols such as TCP/IP, and Internet technologies such as standard web servers. It’s with these standards and the even more important “middleware”, transactional standards such as CORBA (the telephone switch equivalent for computer systems) that modern IT Architectures can be built.
But the desire to have competitive advantage and differentiation will always cause conflict and resistance to standards. We see it today in differing approaches to so-called open standards such as XML.
So on a high level we’ve answered the questions “what is an IT architecture?” and “why aren’t they commonplace?”. Let’s move on to the last of my three questions: “why do you want one?” This is an easy one, because I think most people would agree that proceeding without a plan is likely to get you someplace other than where you want to be and get you there at a higher cost than you anticipated. A few years ago you could have argued that we weren’t far enough along in Brady’s product lifecycle to make IT Architecture feasible. There just weren’t enough standards to build upon. But that is changing, and now is the time to make sure that our corporations don’t metaphorically burn to the ground because our information systems have different hose couplings.
Let me conclude by going back to the home architecture example and restate the importance of starting with the correct goals and vision. In building a home, your goals and vision should be dictated by the potential homeowners. In building IT Architectures, your goals and vision should be dictated by the business owners and their strategies.
