The world of the technical architect SunWorld debuts a new column looking at the world of the technology architect -- here we discuss the design of an architecture and the relationship between business and technology models By Kara Kapczynski

March  1998

An introduction to the basic principles that should guide your IT design. What is an architecture? What is the best way to talk about all the diverse technologies that make up your organization? In the past, people have done this by simply drawing boxes around all the software they use and calling this their architecture. We show you a new way to look at this. (3,100 words)

Mail this article to a friend

o you ever get the feeling that the word "new" is overused?

I've been in the technology industry about 15 years now -- long enough to be completely jaded by vendors' promises of perfect software that has yet to be programmed. Vendors want us to believe that there is inherent good in a product's newness. When it comes to enterprise software, the equation seems to go something like this :

New technology = strategic technology = technology you should buy.

The corollary to the equation goes something like this:

The longer the time your technology has been implemented = the less strategic it is = the more reason it should be replaced.

Here's a frightening thought: Someone might stop reading this article right here, copy what is written above, and actually try to run their IT organization by these "guiding principles"!

The world of the technical architect
Making sense of the promises and pitfalls behind technology is challenging and often confusing. It requires that we keep the existing stuff running and supporting the business, while incorporating technology innovation and using the right technology to address new business needs.

Add to this the upgrade treadmill. By the time you have implemented something in your organization there's a new version out and your stuff is old, and you are made to feel that you are stuck with an old architecture -- a (dare we say the word?) legacy environment.

A new column in SunWorld
There is a lot of talk, these days, about vendors and products, but there seems to be very little talk about putting it all together. Product vendors and technology standards bodies can't seem to sort out the disparate technologies that have been implemented on an ongoing basis over many years, so the work of integration is left to you.

And that's the idea behind this column. Each month, there will be a new article covering architecture issues. The industry offers many options, and is innovating at a rate never seen before. Organizations using technology will always have the need to introduce new technology into their existing environment. We will write about architecting these types of solutions, and provide you with information on how to put it all together.

Architecture: What you've got, what you want
This month, I'd like to introduce the concept of an architecture.

An architecture is the design of all the technology components in an environment, which together support an organization.

This does not mean that whenever people use technology, all the technology is nicely coordinated, purchases are planned events, and all components work harmoniously. The most prevalent architecture is a loose coupling of various hardware, software, and networks. Nonetheless, this loose coupling is the architecture.

Reality means that we will never walk into work some bright and shining morning to find all brand new PCs of the same make and model, a state-of-the-art network with maximum bandwidth across every line, the latest version of every software application, with each package developed with the same tools and technologies, and all customer software development done is a single programming language (Java, of course). Thus, the architecture is what the organization has.

On the other hand, I am not implying that technology deployment should take a chaotic approach. Rather, we need to work with what we have and incorporate additional technologies into the environment in the manner most efficient and beneficial to the organization.

In addition, there are common issues that face us when we put it all together. Even though we will have disparate data-storage mechanisms and a collection of applications, business will require manual or automated integration of the data and applications in the environment.

Here's a list of common themes that I discuss with CIOs:

• Enterprise/extraprise data access and data management
• Integration of various application functionality and processes through middleware
• Proactive heterogeneous systems management
• Exploiting Web-related technologies
• Distributed software/hardware trouble shooting and help desk problem resolution

Instead of focusing on picking the latest, greatest tool, architecture is the ongoing process of designing a technology model that will work for you. With help from other members of my senior technical architect team here at Cambridge Technology Partners, we hope to provide you with a sane discussion of these and other issues that might be presently causing your organization some pain. You should consider this column the Architecture 101 column.

And by the way, I welcome your feedback on this and plan to incorporate it into upcoming columns.

Business models and technology models
Architects think in terms of models. There are many types of models: business models, technology models, application architectures, and enterprise architectures. Although we can define an organization in a number of ways, what is important to technical architects is which models drive which other models.

Sometimes understanding the relationship between the business model and a technology model is easy: We want to sell products via the Internet. At other times, the relationship between business drivers and technology drivers is obscure: We want to upgrade to another version of Microsoft Word. Furthermore, with so much innovation taking place at an ever-increasing rate, and evolving, growing organizations, it is common for the IT professional to feel that he will never be able to deploy a technology model that meets the needs of the business model and business objectives.

Business objectives will always drive changes in the technology. When there is some change in the way that an organization functions, there will be some change in the technology model supporting that organization.

Now and then, we all get that feeling that we will never catch up with the demands of today's competitive, world-focused, ever-changing businesses. However, the future does not have to be bleak -- so long as we design the technology architecture with the objective of supporting a growing, evolving business clearly in mind. That's my role as an architect -- to manage the design and the inter-relationships between the business and technology models.

Here's how I express this relationship. You can see the new process, F, reflected in the technology model.

Types of architectures
Before you can analyze the fit between your business and technology models, or plan technology additions to your environment, you first need to understand your existing architecture. The first step in analyzing your technology model is describing the type of architecture you currently have. Many people skip this step.

I see a lot of environments that have purchased a few products in each product category. If you are wondering how they get this way, I'll give you an example: I did some work at a company that wanted me to deploy technology it had selected to monitor some new applications and servers. The company asked me to discuss monitoring requirements with various people in the organization. As I would have expected, the network management group already had a slew of their own tools in place. The network group was already monitoring stuff --and it was streaming across the system consoles. The group taking care of the Novell server environment already had their own stuff. Likewise, the database group associated with the new applications and servers were giving preference to database management tools that had system monitoring features. I think there were one or two other groups with monitoring technology that were capable of servicing several, if not all, of their needs.

This gets back to my point: You need to know what architecture you have, the technologies you've implemented, and how they are used. This can still be difficult, because "architecture" is one of those great technology terms that no one consistently defines in the same manner.

Here's how I depict the two leading ways of documenting architecture:

Architecture-in-a-box
A popular method for describing your existing architecture is what I like to call "architecture-in-a-box." Actually, I used to be an architecture-in-a-box expert. Now, I look back and say to myself, "people actually paid you to do this?"

Let me describe the architecture-in-box approach. First, you list the names of all technologies that they can think of: operating systems, databases, application development tools, etcetera. Better technologists categorize the terms into more descriptive groups like database server operating system and network management operating system. A good list should contain approximately 87 items. I have seen them done with well over a hundred items, but those tend to be too detailed. Some people will try to get away with 11 or 12 items -- I take this as a warning sign that they may not know anything about technology.

Once the list is produced, each word is placed horizontally and centered in a box. The words are labels. The box can be a square or a rectangle. For example, a box might be labeled, "operating systems." Next, the actual operating systems that are deployed in the environment are entered inside the box labeled "operating systems." Thus, the word "Solaris" could be put in the box. You should use a different font or bold the terms so that you can distinguish the terms from the list from the technologies deployed.

The process continues, and more value can be added by grouping similar technologies in a bigger box for a little boxes in a bigger box technology hierarchy effect. Lastly, one assembles all the boxes into one unit by moving all the boxes next to each other. The one unit is then designated the conceptual model, strategic architecture, or simply named the architecture.

It took me years of looking at these architectures to one day finally get up the confidence to ask the chief architect I was working with if the architecture he had just drawn up wasn't really just a collection of technical terms neatly listed inside a bunch of boxes.

Architecture layout. A.K.A. architecture-not-in-a-box
Architecture layouts or architecture blueprints depict how things are connected in an environment. They are truly more complicated than the architecture-in-a-box since they can not be produced in a word processor.

I like to describe someone's architecture for them as a graphic, and add textual explanations as necessary. The graphic shows how various technology components are linked together. The technology components in an environment are still labeled, but the components are grouped together in a manner that demonstrates how they work together. The value of the graphic is that when it is shown to a technologist, they can understand what your technology model looks like. You can look at the architecture layout in the picture above, and you understand the function of the technology.

Which architecture type is right?
I'm sure you'll agree that today's architectures have become too sophisticated to be expressed as a simple series of boxes. If you look at the amount of technology a business uses, and the number of pieces and parts associated with a software application, it is impossible to deal with integration issues, systems management issues, and problem resolution without having a layout of your technology.

More emphasis needs to be placed on architecture design to ensure that the technology functions smoothly, interoperates as necessary, and that the organization can afford to properly manage and maintain its technology.

Here are some common terms used in architecture design:

• Application Architecture: The set of technology and the way that these technologies work together to support a single business application.

• System Architecture: A group of applications with a common infrastructure and set of technologies that support them.

• Enterprise Architecture: The collection of disparate system architectures in an organization. All of the technology in the enterprise is controlled by the organization.

• Extraprise Architecture: All of the technology in the enterprise as well as that which is used by its trading partners and external customers.

• Technology Architecture: This is a generic term that refers to the architecture for which every level the context applies. For example, the technology architecture of an application is the application architecture. The technology architecture of your company is the enterprise architecture.

Architecture realms
The task of creating architecture layouts for a large organization is truly daunting. If I had enough time I would create massive architecture layouts of the various technology components to my organization. In reality, I could never map out everything unless I was working at a small company. In addition, the question you should ask is, "What parts of the architecture do I need to design layouts for?" Some technology areas of the organization are stable, and mature. There is little change in the business model, and no innovation in the technology model. These are good technology areas to depict as a single realm, show where it interfaces to other technologies, and leave it at that.

This scoping approach encapsulates key areas into "architecture realms." Each realm is merely a grouping of technology. You can choose which realms you need to go deeper into and develop a graphical layout, and which areas require little architecture work and can be left as a "realm." Often, technologies are less important to the architect because they represent technology that has been outsourced, or might be dictated by a package that functions as black box (that is, unmodified).

Yet another area in the company may be supporting an intranet. The intranet functions differently from the other areas, and uses another set of technologies. However, if the company is also working towards supporting external trading partners with some of the functionality in their intranet, then this realm would be a good area for the technical architects to create an architecture layout.

The important thing to remember is that we can make groupings out of the technology model, and that each grouping or "realm" supports the business model in some way.

Band-aids
Often, the level of integration is as simplistic as a few band-aids that have been implemented on an ad-hoc basis. We will discuss the various approaches to enterprise integration in future columns. For now, "band-aids" will have to suffice. These "band-aids" represent infrastructure technology such as managed file transfer (or just plain, old un-managed FTP and extract files), database gateways, HTTP and Web information, or authorization and authentication information. A more sophisticated architecture will have an organized approach to integration and middleware services. The integration can then be drawn on an architecture layout.

For most organizations that I see, there are random connections and extract files bridging the gaps between the architecture realms. Thus, this is a great area for architecture work -- to actually design and decide and what level of integration will be achieved.

I've mentioned that architecture is an ongoing design process. This means that our architecture layouts and our designated realms will always be changing, and we will be adding new technology to the environment. The corporate move to the Internet brought in a great number of new technologies to the existing enterprise architecture. How will the development of Java applications affect your organization and its architecture? What impact do channel distribution and the so-called push technologies have on your applications and on your network?

And more than that, the Internet has expanded our notion of architecture to include technologies that are not even owned or controlled by the enterprise. These days, the challenge facing technical architects goes beyond designing enterprise architectures to meet strategic objectives. Today's best IT architects are modeling for future applications and the extraprise architecture.

Designing an evolving architecture
The rules for creating and extending an architecture have changed over time. Large organizations utilize heterogeneous technologies, buy from many vendors, implement some technology internally and outsource other areas. Having the necessary skill sets and being able to attract and retain key personnel is an ongoing concern for most CIOs. Applications might have become easier to develop, but they have become more difficult to manage and troubleshoot over a distributed environment. Many products are not thoroughly tested, and result in unexpected issues in a production setting.

Designing a new part to an enterprise architecture has become a process of balancing the choices. The design process requires optimizing for many variables and dependent factors that influence each other, including:

• Functionality
• Evolution/the amount of change
• Initial cost
• Cost of ownership/management
• Resources, work effort/skills
• Software partitioning/tiers
• Common services/infrastructure/reuse
• Package/tool maturity/vendor relationship
• Integration with other systems
• Scalability of the solution

Every organization has it own priorities and objectives and will balance the solution accordingly. Where high availability is a concern, the architecture will be designed differently than for organizations where this is less of a concern. For high availability, I often implement sophisticated systems management infrastructures that can cut over to a second or third hard disk as necessary, and escalate pages to administrators to inform them of the automated actions.

For another example, I am now working on an architecture for a company where time to implement and reduced risk are the most important factors. All the technology will be deployed within nine months for this client. The project teams could not risk memory leaks in the applications or having unforeseen bugs in the JVM causing delays, so although almost half of my projects now use Java, this development environment is not Java.

Organizations that incur more change design their architecture to be flexible. Other architectures must interoperate with considerable amounts of legacy technology.

From a technology aspect, we can offer several architecture design options for application architecture, systems architectures, and enterprise and extraprise architectures. However, the weight that we put on these factors will skew a technology architecture recommendation towards one solution or another.

I hope that this column will help you model your organization's architecture and understand what is in place. You need to think about the factors that effect technology decisions in your business. In the future, IT Architect will address the technology design process, and the people, processes, and technology that are encompassed by an architecture. Let me hear from you. I welcome your comments.

About the author
Kara Kapczynski is a Technology Director with Cambridge Technology Partners. Reach Kara at kara.kapczynski@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1998/swol-03-itarchitect.html
Last modified: