Make the architecture work

Making architecture matter make architecture work

This article was originally published in IEEE Software magazine and is currently provided to you by the INFOQ and IEEE computer associations.

As an architect, we want our architecture to work. We hope to achieve our grand design through the project, one small step at a time, each step is the perfect part of the big problem of software architecture. We want to provide assistance to the entire company's developers by telling them to use a specific database or Web server because we want their code to be easy to maintain and adhere to our good architectural design principles.

But the reality is rather tricky. At Statoil (Norwegian National Petroleum), we used to like fancy portal architectures with many models and complex designs, but we found that no one looked at what we wrote or did as we said. Over time, this brings a lot of extra costs because we're struggling to maintain a variety of Web server ecosystems, middleware ecosystems, and so on. A few years ago, the company began to focus on compliance management after several accidents and realized something called an enterprise management system. This new approach to communication in Statoil operations has given us a golden opportunity to make our architecture more known and more influential.

A new scene?

Most large companies have IT departments, and Statoil is no exception. Our IT organization has more than 1000 employees, contractors, consultants, and they are all over the world. They need the right it tools to handle the work at hand. In such a large organization, we cannot rely on all stakeholders of the personal relational Solution architecture (business analyst, software developer, it manager, base operator, etc.), instead, we need to use other methods to communicate.

The traditional solution to this problem is to create a software architecture document, or a slightly more fashionable approach that leverages the architecture portal for stakeholder consultation. Because it is important to keep the software architecture right, we have established a link to the architecture Portal on the home page of the enterprise so that stakeholders can easily find it. We found that in an oil company, it was not seen as the core of the business, so our architecture portal was hard to find, no matter how much work we did for IT organizations, still very few people came to consult. When they are consulted, they usually do not understand the schema, or when they cannot associate the schema with their work. After several chances, management decided to pay more attention to corporate compliance requirements in order to meet the various needs of Norwegian oil operations. This work is driven by the upper level, with clear compliance goals, from CEO to executive vice president, and vice president of the world in charge. There was a lot of demand in the corporate management system, and thousands of documents described in detail the various requirements for offshore oil construction to IT security. Although management wants Norwegian oil employees and contractors to understand these requirements, these documents are in fact difficult to read and understand. In addition, they often contradict each other, and it is difficult for the reader to figure out which needs are valid.

Keep it organized.

To address the challenges faced by the company's management system, management decided to follow the principle of "let the system organize employees, let the workflow organize work", according to the workflow organization requirements. Develop a process for all day-to-day repetitive work, and then give someone the maintenance to ensure that they are constantly updated. These process owners are also responsible for appropriate best practices, including IT tools. Equip each process owner with an assistant to help develop best practices and requirements analysis in their respective areas. When these process development is completed, all old documents from the corporate management system are decomposed into individual requirements and delegated to the relevant process activities. In the process of this work, the requirements are simplified and adjusted to the appropriate level of detail.

In it, we have our process owner (who is also the CIO) and have developed a series of processes that describe how the Norwegian oil it work is performed.

Figure 1 shows an example.

Figure 1. A workflow example in the IT field. The information it shows includes which events start the process, what roles are involved, which activities should be executed, and when the process ends. Related to each activity are requirements and best practices, and it is easy for readers to see what they want to see.

Let management focus on compliance and requirements, the company spends a lot of resources on training and ensuring that the content of the management system is up-to-date. Norwegian oil also spends a lot of resources on the management system itself, so that users can easily find the information they need.

New features and benefits

An important feature of our management system is the ability to assign effective processes or requirements to specific areas. These effective areas are based on the organization, geography, role, or combination of these. When a user browses to a management system, the system displays related processes and requirements based on the person's organizational department, location, and role, hiding those unavailable requirements that may confuse the user.

As a software architect, we immediately saw the potential of the management system in communicating architecture, and personalization meant that we could show SAP developers the architecture and requirements associated with SAP development, and also show Java developers the architecture and requirements associated with Java development. (see Figure 2) Thanks to this management system, we are able to spread our architecture ideas across the organization and spend less effort than traditional file-based approaches, but with greater impact. Architecture and requirements are embedded in the system around the developer, through personalized features.

Figure 2. Different needs for different users (a) show SAP developers an activity from the management system (b) the same activities shown to Java developers. By showing only the relevant requirements to the user, the user only focuses on what they really want to focus on.

After a few years, we began to review the role of enterprise management systems in communicating architecture requirements. By developing enterprise standards and requirements, we have reduced the number of database platforms used and shared their usage. Our database operations now maintain servers and databases equivalent to 10 times times the size of 10 years ago, and this number grows by 15% per cent a year. However, the number of our personnel is equivalent to 10 years ago, and we have no intention of hiring more people. The same thing happens in other parts of the IT organization, such as networking facilities, Web services platforms, and integration software.

Another look at the effect is that the reliability of our applications and facilities has improved, and they have become so robust that there is virtually no interruption in the accident. In our vision, it is becoming more and more important to Norway's oil operations. With no IT support, there is almost no process to work, and it is now the essential department to keep the company's applications and facilities running 24 hours a day 365 days a year. The enterprise management system will become a powerful tool, a highly available it portfolio that communicates the necessary requirements.

The most important thing is that we learn to make the architecture work, we have to make it available to all stakeholders, and we can't expect all stakeholders to come to us. Only by making the architecture requirements run through IT organizations can we reach more stakeholders than traditional architecture documents or portals, and make the architecture system more important. Even if your organization does not have a management system like ours, you will reach out to more stakeholders and play a bigger role through the management system that you have, rather than doing it in a different way.