Making Architecture Matter

This article first appeared in IEEE Software magazine and is brought to you by InfoQ & IEEE Computer Society.

As Architects, we want our architecture to matter. We want projects to implement our grand designs, one little step at a time, with each piece fitting perfectly into the big puzzle that is software architecture. We want to reach out to developers across the company and tell them to use a particular database software or Web server because we want their code to be easily maintainable and follow our sound architecture design principles.

But reality is a bit trickier. At Statoil, we used to have fancy architecture portals with lots of models and complex designs, but we found that nobody read what we wrote or did what we said. Over time, this led to extra expenses as we struggled to maintain multiple Web server ecosystems, middleware ecosystems, and more. A few years ago, the company increased its focus on compliance management after a few accidents and implemented what is called a corporate management system. This novel approach to communicating all the different requirements Statoil faces in its operations gave us a golden opportunity to make our architecture better known and increase its impact.

A New Drawing Board?

Most large companies have an IT department, and Statoil is no exception. Our IT organization encompasses more than 1,000 employees, contractors, and consultants spread all over the world, all of whom need the right IT tools for the task at hand. In such a large organization, we can't depend on personal relations to reach out to all the architecture stakeholders (business analysts, software developers, IT managers, infrastructure operators, and more) but instead have to rely on other means of communication.

The traditional approach to this problem is to create a software architecture document or, more recently, an architecture portal that stakeholders can consult. Because it's so important to get the software architecture right, we wanted a link on the first page of the corporate intranet portal, so that all the stakeholders could easily find it. We "discovered" that, in an oil company, IT isn't considered to be at the core of the business, so our ne architecture portal was difficult to find, and no matter how much we worked with the IT organization, staffers rarely consulted it. When they did, they had problems understanding it and making it relevant to their own work.

After some close calls, management decided to increase the focus on corporate compliance to enforce all the different requirements Statoil faces in its operations. This effort was driven from the top, with clear compliance goals and expectations handed down from the CEO to executive vice presidents to vice presidents to managers to individuals working around the world. At the time, these requirements were found in the corporate management system in the form of thousands of documents detailing everything from subsea oil well construction to IT security. Statoil employees and contractors were expected to know them, but the documents proved difficult to read and understand. In addition they often contradicted each other, confusing the readers as to which requirements were valid.

Get Organized

To address the corporate management system's challenges, Statoil decided to organize requirements according to work processes, following the principle "We use the organization to organize the people and the work processes to organize the work." For all regularly repeated work, a process was developed and assigned an owner to maintain it and ensure that it's up to date. These process owners are also responsible for ensuring suitable best practices including IT tooling. All process owners have a staff to help them develop best practices and requirements for their respective process area. After these processes were developed, all the old documents from the corporate management system were broken up into individual requirements and assigned to relevant process activities. In the course of this work, requirements were also simplified and adjusted to a suitable level of detail.

Within IT, we got our own process owner (who is also the CIO) and developed a set of processes describing how IT work should be performed at Statoil. Figure 1 shows an example.

(click here to enlarge)

FIGURE 1. An example work process from the IT area. It shows which events lead to the process starting, which roles are involved, what activities should be performed, and when the process ends. Attached to each activity are its requirements and best practices, making it easy for the reader to see exactly what is expected.

Given management focus on compliance and requirements, the company spends a significant amount of resources on training and on ensuring that the management system's content is up to date. Statoil also spends a lot of resources on the management system itself to make it easy for people to find the information they need.

New Features and Benefits

An important feature of our new management system is the possibility of assigning specific areas where a particular process or requirement is valid. These validity areas can be based on organization, geography, or role, or a combination of these. When a reader looks through the management system, it uses that person's organizational unit, location, and role to display only the relevant processes and requirements, hiding nonapplicable requirements that might confuse the reader.

As software architects, we immediately saw the potential in the management system for communicating architectures, and the personalization features means that we can show SAP developers architectures and requirements that are relevant for SAP development, and show Java developers architectures and requirements that are relevant for Java development (see Figure 2). Thanks to the management system's implementation, we were able to spread our architecture throughout the organization with much less effort and much more impact than via the traditional document-oriented approach. Architectures and requirements are now available at the developer's fingertips, made relevant by the personalization features built into the system.

FIGURE 2. Different requirements for different readers. (a) An activity from the management system as it's displayed to a SAP developer; (b) the same activity displayed to a Java developer. By only showing relevant requirements to the reader, he or she is made aware of exactly what's expected.

After a few years, we're now starting to see the effects of using the corporate management system to communicate architecture requirements. By developing corporate standards and requirements, we've been able to reduce the number of database platforms in use, as well as how they're used. Today, our database operations department operates 10 times the number of servers and databases compared to 10 years ago, and that number is growing at a steady 15 percent every year. However, we still have the same number of people as we did 10 years ago, and there are no plans to hire more. We see the same kind of effects in other parts of the IT organization such as network infrastructure, Web server platforms, integration software, and more.

Another observable effect is that our application and infrastructure stability has increased and become so good that major outages are rarely seen anymore. As we look forward, we see that IT is becoming more important to Statoil's operations. Very few (if any) of our processes can function for long without IT support, and it's becoming imperative to keep the applications and infrastructure running 24 hours a day, 365 days a year, to support the company. This is where the corporate management system will become a powerful tool, to communicate the necessary requirements for an IT portfolio with high availability.

The most important lesson weve learned is that for architecture to matter, we have to bring it out to all stakeholders; we can't expect stakeholders to come to us. Only by making the architecture requirements integral to the daily work throughout the IT organization have we been able to reach more stakeholders and make architecture matter more than we would have by using traditional architecture documents or portals. Even if your organization doesn't have a management system similar to this, you'll reach more stakeholders and make more impact by using whatever management system you have instead of implementing something outside existing practices.

About the Authors

HARALD WESENBERG is a software developer with more than 15 years' experience in developing business-critical enterprise applications for the oil and gas industry. He's the enterprise solution architect for Statoil, a global Fortune 100 oil company, and frequently speaks and writes of his experiences at conferences around the world. Contact him at hwes@statoil.com.

EINAR LANDRE is a software professional with 25 years' experience as a developer, architect, manager, consultant, and author/presenter. He works as a line manager at Statoil. Contact him at einla@statoil.com.

This article first appeared in IEEE Software magazine. IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.