The IT Environment

Sandra Y. Jeffcoat and Miriam Grace

March 2007

Summary: Like good actors, architects play many roles—from archaeologist to inventor to mediator to security agent to leader—but often it seems as if technologist were the least of them. (5 printed pages)

Contents

The IT Environment
Architect as Archaeologist
Architect as Inventor or Innovator
Architect as Mediator or Negotiator
Architect as Security Agent
Architect as Leader
Sources

The IT Environment

Between the two of us, we have been architects for more than a combined 40 years. While working in this capacity, we have had to deal with many situations in which someone on the outside looking in might ask, "What on earth does that have to do with information technology!?"

As system architects, it is assumed that we are expert technologists. We are expected to provide expert technical solutions to business problems, and it is expected that those solutions integrate well with existing and planned computing system-architecture components. In performing such activities over the years, we have had to learn many aspects about: engineering; manufacturing; banking; finance; sales and marketing; military operations; vendor operations; laws; standards and requirements for information protection; national and international standards, relative to information transmission and use of the Internet; and more. We have also found that our profession has placed us in roles that we never dreamed of performing. We have found ourselves being archaeologists, inventors and innovators, mediators and negotiators, leaders, and even security agents.

Architect as Archaeologist

Archaeologists present information about the past and about human culture through research and discovery methods. Their discovery process involves uncovering details from documents and artifacts that often are found in the ruins of ancient civilizations. In a similar fashion, an architect determines a solution that is based on documentation that is presented by the user community. This requires an architect to research and discover the details for solution development. Also, like an archaeologist—and to save both time and money—an architect reviews and analyzes any prior documentation regarding implemented systems, to determine the reusability of various components. After the reusable components have been identified, an architect continues the archaeological journey by searching reuse libraries or pattern repositories, or other resources for software or design solutions that will satisfy the portion of the solution that remains.

Archeologists fill in the gaps in their understanding when key information or parts of artifacts are missing. A prime example is a search for dinosaur remains, in which the archaeologist might have only found parts of skeletons. In recent years, archaeologists have used forensic science to piece together a replica—being careful to explain their methodology and how they determined the shape and size of the missing parts of a skeleton. When the skeleton is complete, archaeologists have been able to provide a vivid picture of what a prehistoric animal might have looked like, where it lived, what it ate, and how it protected itself from its enemies. And we can apply this analogy to being an architect operating in an information-technology (IT) context.

In an IT environment, as computing system architects, we have been given requirements by our business partners. Often, we discover gaps or missing elements or processes, or we realize that there are conflicts in requirements that are provided by different groups of stakeholders. Like an archaeologist, we have used one of many methodologies to guide us through the process of clarifying those requirements and reaching resolution of the conflicts. Our discovery process usually involves holding information-gathering sessions in which we present what we have learned to that point, followed by inquires that will allow us to receive additional information.

Notice that we did not say that we "complete the information." This is because our experiences have taught us that we seldom obtain complete information in such sessions. We have found that, like an archaeologist, we must dig and explore to complete the requirements picture. That exploration includes looking at existing systems, reviewing existing documentation, and even shadowing a particular individual who performs a particular business process. All of this work allows an architect to put together a complete picture of what is being asked for, in terms of system requirements.

Operating as an archaeologist does not end with the requirements-gathering. We have found that such skills are needed in almost every phase of the Software-Development Life Cycle (SDLC). When our business customers are not quite sure how they will use a certain type of report, or they are not sure how they want the computer interface screens to look, or what information should be grouped in what order, we begin an exploration that is more commonly referred to as prototyping.

Prototyping—in some ways analogous to forensic development of skeletal casts that are used by archeologists—allows the IT organization to present a design without fully developing the system, which saves both time and money in the long run. The art of exploration is also employed when looking for useful tools or Commercial Off-the-Shelf (COTS) products to satisfy the requirements. It is also useful when tuning or debugging a system. In short, we have found that a large part of an architect's job is exploration and discovery, just as it is for an archaeologist.

Architect as Inventor or Innovator

Today, global demand for oil has caused many challenges to obtaining the oil that is needed to run industrialized nations. Oil shortages have caused oil prices to skyrocket—affecting transportation of goods and people worldwide. So, what happened? Some inventors came up with a car that would run on alcohol. Problem solved! Well, not exactly. Alcohol has been used in the engines of racing cars for almost 80 years, but commercial car manufacturers still resist switching over to this means of energy for car engines. Still, it highlights our point. Inventors create alternatives to what exists—in this case, alternative fuel for cars that are now being fueled by gasoline. Inventors (or designers) create things that have not existed before: new devices, drugs, process, or procedures that solve problems. Architects certainly do not create drugs; however, architects do design devices (software or hardware), create new methods for using existing devices more efficiently, architect seamless interfaces between components so that data can flow smoothly across systems, and create processes or procedures to solve problems. When not creating, architects are improving existing devices, streamlining processes or procedures, consulting with business customers to help them transform their business processes, and performing multiple other tasks that we place in the innovation category. Whether classified as an inventor or innovator, we have found ourselves, as architects, helping the business customers explore useful and new applications of technology to enable them to do their work faster, better, and cheaper.

In the beginning stages of our technology careers, our lives were a little simpler; all we had to do was convert an existing business process to an electronic media. Today, our business partners are challenging us to new levels of creativity. They are requiring us to find new and innovative technical applications that are geared toward increasing their market share. As architects, we have found that we must always be ready and prepared to accept the challenge of creativity. Being ready and prepared not only includes keeping our education in technology advances current, but it means that we must also be able to think outside the box. We have found, more so today than in the past, that innovation is one of our most important products.

Architect as Mediator or Negotiator

As technologists, we have found ourselves involved in many different types of negotiations. We have found ourselves trying to convince coworkers or our leadership team that our idea will work, or offering multiple options for their consideration. We have experienced situations in which we knew up front that there would be issues down the road, situations in which we had to influence others to be proactive.

Oh, and then there are the politics! Negotiating around those are always fun! There have been times when politics have become "show-stoppers" and we were unable to advance in the development life cycle until the issues were resolved. In these cases, it is incumbent on the system architect to try to resolve the problems that often escalate into political conflicts. But a cautionary word is warranted here: The old poker adage "You have to know when to hold 'em and know when to fold 'em" applies. A system architect has to know when to wade into a problem space, and when to back away and let the "chips fall where they may." The ability to know when to engage and when to disengage is a well-honed skill of an experienced system architect. Unfortunately, it is learned through mistakes—the most painful but effective teacher.

There are also situations in which we have found ourselves in the middle of users, managers, developers, or other business players who are having a technical disagreement. No matter what the mediation or negotiation situation in which we have found ourselves, we have found that our success depends on our resisting the temptation to take sides or inject our own personal views. We always obtained success when we dealt only with facts and data and worked to gain consensus. When consensus was not possible, we looked for outside help or—where possible—made a unilateral decision, based on the facts and data of the situation.

Architect as Security Agent

News flash: Today, ABC Company reported that the identities of more than 7,000 employees were stolen because of a security breach in its computer systems. Now, ABC Company is facing the biggest lawsuit in its history for its carelessness in protecting its employees' personal data.

News flash: XYZ Company and ABC Enterprises are battling it out in court over breaches in trade secrets. XYZ Company is accusing ABC Enterprises of breaking into its computer systems and stealing plans and designs for its new products.

These news flashes might not be real, but they certainly reflect reality. Problems like these have caused many companies to add the duties of a security agent to the role of architect. Today, the computer systems of companies carry their most vital resource: the information about their products, processes, and employees. A company's computer systems and data-storage devices often contain its entire knowledge base—making them enticing targets of competitors or enemies who might wish to disrupt vital industries. So, what does this all mean to an architect?

As architects, we have the responsibility to act as one of the company's security agents when it comes to controlling access to data that resides in computer systems or the networks that keep the computer systems running. In this capacity, it is our job to put in place the best security model possible, to protect the system and its data from intrusion or destruction. Having a viable disaster-recovery plan in place for any system that we design and implement is a vital responsibility. The destruction of a computer system, whether through human intention or natural disaster, can be just as damaging to a company as theft of its data. So, as an architect, we must take our role of security agent very seriously.

Architect as Leader

An architect is not just a technologist, an archeologist, an innovator, or a security agent. An architect must be a true leader! What does that mean?

We have found that in addition to all of the skills listed earlier, an architect must have strong people skills and the ability to apply influence—key components of leadership. An important part of leadership is the ability to know when to lead versus when to follow (sort of analogous to "when to hold 'em and when to fold 'em," as mentioned earlier). The skill with which we switch between leading and following has a lot to do with our understanding of the difference between formal and informal power, and when to apply each. Formal power (or what is referred to as "power over") and informal power (or what is referred to as "power with") are very different in terms of the human dynamics that are involved. More often than not, it is the informal power of an architect (the ability to influence without coercion) that yields more favorable results faster than the exercising of any formal power relationship.

In any case, we have found, most often, that we operate in an environment in which we have little formal power (authority). The role of architect is one of being "in service" to others, and this means that we normally have very little formal authority to direct the actions of others. Generally, the individuals for whom we are developing a technical solution hold higher-ranking positions in the company and consider us to be outsiders to their organization.

The IT organization—and therefore the IT environment, in particular—is characterized by its lack of formal power within a company, unless information technology is the primary product or core competency. When IT is a support organization, which it is in most enterprises, the computing systems architects must turn to their skill in the use of informal power relationships to guide the design project toward a successful conclusion. The exercise of informal power relationships might take the form of negotiation or mediation, as we discussed earlier, or it might involve researching and using company directives or proven results to drive home our convictions.

Certainly, when we create a focus on learning within our design team and build a relationship of mutual respect over time with our customers, challenges to our leadership come less frequently. As architects, we must understand our customer's business well enough to be able to advise customers in their language and by using real-life examples to which they will relate. We have to acknowledge that we have important insights to offer to our customers, without being arrogant. We have to have the patience to listen, and yet the confidence to speak up when required. More often than not, we find ourselves educating the customers about their own businesses—which has to be handled very carefully or we might be seen as "stepping outside of our boundaries." But our business savvy is extremely important, and the better our understanding of how the business context and the IT environment can blend, the better the product that we can deliver to our customers.

In short, an architect is a leader who does not necessarily have formal power. And yet, not having formal power does not exclude an architect from displaying classic leadership attributes.

Sources

Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Boston, MA: Addison-Wesley Professional, 2004.

McGovern, James, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture. Upper Saddle River, NJ: Prentice Hall PTR, 2004.

Rozanski, Nick, and Eóin Woods. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Boston, MA: Addison-Wesley Professional, 2005.

About the authors

Sandra Y. Jeffcoat is a member of Boeing's Technical Excellence Program, a 2005 National Women of Color in Technology and 2007 National Society of Black Engineers (NSBE) Golden Torch awards winner, and a Ph.D. candidate for the Antioch University Leadership and Change Program. Sandra has more than 28 years of technical experience for such companies as the Boeing Company, Eastman Kodak, NCR, Mead Paper Corporation, AT&T, and various government agencies.

Miriam Grace is an Enterprise Systems Architect and a member of the Boeing Technical Excellence Fellowship. She has over 20 years' experience as a computing systems architect, with a specialty in business-process management systems. Miriam is a published author, holds a Master's degree in Systems Design, and is a Ph.D. Candidate in Leadership. She designed a learning system that has provided a curriculum of foundational skills for software architects at Boeing.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.