by Daniel Akenine

Contents

Introduction
Why We Need Architects
A Process to Map Artifacts to Levels
Architect Roles
Biggest Challenges
Conclusion
Resources

Introduction

In this article, we first examine why there is a need for IT architects. We then describe a study undertaken by IASA Sweden to better understand IT architecture, which entailed a process of mapping the artifacts produced by architects at different levels in an organization. Finally, we discuss four architect roles that IASA Sweden, as a result of the study, recommends for a typical organization.

Why We Need Architects

As you are well aware, IT roles in general are relatively new compared to other professions and the associated responsibilities have been evolving over the past decades. This is not surprising as the use of IT and software has changed continuously since computers and IT systems were introduced. IT and software have been integrated into many people's lives, and technology is easier to consume and use than ever before. Does that mean IT systems are less complex than they used to be?

There are really two trends going on in the industry:

• IT gets easier and easier.
• IT gets more and more complex.

With increasingly powerful tooling and modeling, producing new software solutions gets easier and faster. You can create an advanced SOAP-based service in less than a minute. On the opposite side, however, the fundamental architecture of these solutions is more complex than it used to be. Why? Well the simple answer is because we expect much more from today's software; it has to do more complex things.

Many years ago, I got a telephone call from a friend. Suddenly, he told me he was strolling around in the city center while talking to me. I was amazed. Obviously, I had heard of mobile phones previously, but I never had actually spoken to somebody using one. Not so many years later, a mobile phone is an integrated part of my life. The technology does not amaze me anymore; on the contrary I get very annoyed when the technology does not perform as I expect it to. Traveling by train in a tunnel, I still expect the mobile phone to work even though I know this is a big technology challenge. My expectations just get higher and higher. This is the exact same way software works.

Twenty years ago, we accepted a simple editor for text processing; today we expect a sophisticated software solution that checks spelling, formats, visualizes, collaborates, and so on. Think about it, a simple modern distributed application probably has a more complex architecture than the high-end COBOL application running in the heart of your bank of choice. This is one of the reasons why IT architecture has a great future; to control and master these modern, complex, and integrated solutions.

In this context, let's consider some of the reasons often given for why architects are important.

We Need Architects to Deal with Complexity

Modern distributed solutions are more complex today than they used to be. There are really two types of complexity in software solutions: fundamental complexity and accidental complexity, as described by Fred Brooks in 1986. Fundamental complexity is embedded into the business problem that the software is going to support. Some business problems presented as complex can actually be simplified; in other cases, the business complexity is inescapable. Software solutions for fundamentally complex business problems need a skilled architect to understand and model the problem correctly.

Accidental complexity is different; it springs from the technological and architectural choices made while solving the problem. For example, how much flexibility for change should the solution have? Decisions on architectural qualities, such as manageability, scalability, security, and reusability, must be made with input from multiple stakeholders whose needs may be at odds. These decisions determine the accidental complexity, and balancing them correctly is one of the most important tasks for an architect.

We Need Architects to Deliver Business Agility

The idea that IT can deliver business agility is frequently heard. However, has the correlation been proven? Certainly, bad architecture can make a business inflexible and slow to act. Many large organizations have invested in IT for many decades now. In the last 10 years, investments in IT have been driven largely by the shockwaves from the Internet revolution, a revolution that has changed the way organizations interact with their customers—generating new types of information in documents, e-mail, portals, and so on. However, many of these investments were made with little care to any enterprise-wide strategy or architecture, and some organizations now refer to the last decade of IT investments as a "Software Crisis."

We are experiencing the cumulative effects of large numbers of short-term and isolated decisions. The cost of changing the software solutions to support new innovative processes or business capabilities is getting out of proportion. To make small changes in the business model or process takes so long or costs so much that they are just not done. This is an example of when IT is bad for business agility; in the end, we need to fix that. Who is better suited to fix that than an architect?

We Need Architects to Reduce the Cost of IT

As others such as David Anderson have written, the cost of managing your existing IT is often as high as 70-80 percent of your total IT budget. More often than not, projects under time pressure result in decisions which multiply life-cycle costs during operations and maintenance. Disparate solution designs and technologies from different projects drive total costs and dilute skill sets. Complex and unknown interdependencies lead to unexpected consequences and costs. Architects can make a real difference in cost reduction; by architecting quality solutions for manageability and supportability.

We Need Architects for Better Business Alignment

In the early days, we used IT primarily to automate manual processes. We used IT to lower costs on information transactions and to store and query data in ways that had not been possible previously. However, those quick wins will someday come to an end. Some organizations have already used IT very effectively to automate and support their business processes, and now they want to move on. It is time to do more sophisticated IT investments aligned with the business strategy and actually use IT to differentiate a company from its competitors.

We need architects to create long-term and short-term strategies for how to use IT in the most effective way for the business.

A Process to Map Artifacts to Levels

Clearly, we need architects. However, architects do not play the same role in every project or company. What kinds of roles should they play, and how can they work with other architects and team members effectively? What we need is a framework for delivering new IT capabilities that supports and improves the current business model, in which different kinds of architects can work together in a consistent way.

The first problem you encounter when you start discussing different roles is the number of perspectives and roles out there. IASA found more than 50 different roles: Although many roles were more or less equivalent, many organizations have created their own roles with unique deliverables. This causes a lot of problems. For instance:

• The same architect role has different deliverables between organizations.
• Organizations may have different roles, but they produce the same deliverables.

How can an architect determine best practice, get training, and have a career in the profession when the roles are so murky?

In June 2007, IASA Sweden put together a working committee with different types of architects from different sectors of the industry with the goal to create general recommendations for more consistent architect roles. To avoid being locked into specific roles too early in the process the committee decided to focus on something that turned out to be very similar between organizations: the artifacts that architects deliver, such as use cases, IT strategies, security strategies, deployment models, and so forth.

The group found approximately 40 different artifacts that could be agreed upon. The next step was to map those artifacts into three different levels in an organization to see if they would form some kind of natural cluster. The levels were defined as:

• Level 1. Architects create strategies together with the business on how to use IT in the business in smart way. Policies and principles are created here that influence the whole organization. Examples of level 1 artifacts include city plans and strategies.
• Level 2. Architects create artifacts which support the mapping between business and technology. At this level, architects try to understand the processes of the organization and how they can be improved using IT capabilities. Examples of level 2 artifacts include process maps and service maps.
• Level 3. Architects produce artifacts that model the technical architecture, trying to create good solutions, which are cost-effective, scalable, flexible, and so forth. Examples of level 3 artifacts include application models and data models.

These levels do not necessarily map to architect roles in a simple way; an architect role can operate on several levels. As an example, an enterprise architect can work on both high-level policies as well as technology polices if they are considered to be important for the whole organization.

After six months of workshops and reviews, the committee released its recommendation for four architect roles, based on the three levels and 40 artifacts:

• Enterprise architect
• Business architect
• Solution architect
• Software architect

The four roles overlap, but they do not necessarily report to each other (see Figure 1).

 

Figure 1. Architect roles; note that the roles do not necessarily report to each other.

Architect Roles

Let's explore the definitions and significance of the committee's recommendations.

Enterprise Architect

Typical artifacts include: IT strategies, capability maps, city plans, integration strategies, as-is/to-be analysis, architectural principles, gap analysis, life-cycle analysis, application portfolio strategies.

Description: The mission for an enterprise architect (with IT focus) is to support the business strategy of the organization with IT solutions and information. The enterprise architect, or a group of enterprise architects, should be responsible for the overall strategy regarding IT capabilities as well as to ensure that the IT architecture is cost effective. In some organizations, it may be appropriate to use enterprise architects in governance functions and to regulate enterprise-wide standards for communication and messaging. In other organizations, these responsibilities may be delegated to specific governance or integration centers, where the enterprise architect is a representative.

The role often reports to a CIO or to a chief architect. An enterprise architect owns strategies at several different levels in the organization—from standards that have a global impact on the organization to strategies regarding things such as security or infrastructure.

A classic analogy is to compare the enterprise architect to a city planner who, using strategy, planning, and regulations, is responsible for different functions in a city that must work together effectively.

The use of enterprise architecture is still immature in most organizations. As IT departments evolve and become more closely aligned with the business departments, we expect the profession to mature and become clearer over the years to come. We believe that growth in tooling and evidenced-based best practice from the scientific community will also influence this profession.

Competence: Deep knowledge in both business and IT; leadership and negotiation skills; experience in governance, project management and economy; knowledge in enterprise architecture and business modeling.

Business Architect

Typical artifacts include: process maps, use cases, information models.

Description: Business architects work very close to the business and understand in detail how the organization works. They are active in modeling processes in the organization and support solution architects with analysis and requirements on new or existing solutions. They understand how the IT systems support the business and suggest improvements together with enterprise architects. Business architects are active in ongoing projects in the organization using their influence to ensure that projects deliver benefits to the business in an optimal way.

Business architects are often involved in areas related to general business and process improvements. The business architect is also a very important resource in every IT project in the organization.

Competence: Deep knowledge in the business; process modeling; requirement analysis; workshop leader skills.

Solution Architect

Typical artifacts include: application diagrams, system maps, service interfaces, technical interfaces, integration strategies.

Description: A solution architect works with the design of IT solutions based on requirements from the business, making use of existing IT capabilities and services in the organization.

Solution architects have a special responsibility to reuse existing functions and services. They align new solutions to the current architectural principles regarding standards and integration in the organization. They balance the functional and nonfunctional requirements with necessary prioritizations and compromises. The goal for the solution architect is the success of the current project, in addition to how well the project aligns to the architectural principles and how well it reuses existing capabilities.

When organizations move from traditional applications to integrated solutions and services, the role of the solution architect becomes more and more important. The role of the solution architect is clearer in larger projects, particularly when many systems are involved. If the project is small or the application is isolated, this role may not be necessary in the particular project.

One could also argue that the solution architect is a natural evolution of the traditional system architect role. Moving away from systems to solutions generates new competencies and responsibilities.

Competence: broad and general technical knowledge, as well as deep competences in things like infrastructure, data models, service orientation; good understanding of enterprise architecture.

Software Architect

Typical artifacts include: frameworks, class models, patterns, aspects.

Description: A software architect works with the structure and design of software systems. Software architects work with both functional requirements as well as different architectural quality attributes such as flexibility, performance, reusability, testability, and usability. Some quality attributes obviously may be shared with the solution architect. They prioritize and optimize the different quality attributes with respect to cost and other constraints. The focus for the software architect is primarily the current project, whereas the solution architect has a wider focus to reuse existing assets, policies and regulations, although this could apply to the software architect as well if the organization finds it necessary to have strict guidance in place for software development.

The role of the software architect becomes more and more important as the complexity of systems continues to increase.

Competence: deep knowledge in programming, frameworks, standards and technical modeling.

Biggest Challenges

To get a broader perspective, we also want to bring forward some of the challenges concerning the roles for architects. For this, we turned to Sten Sundblad, chief architect at Sundblad & Sundblad, and Pontus Gagge, an enterprise architect at Sandvik Corp., to ask them what they think are the biggest challenges.

Sten: I believe that the most important challenge is about helping achieve business agility.

When a business is challenged from the outside, it often needs to change parts of its business strategy. Almost without exception, this means that it has to change its business architecture (meaning its business processes), too.

One of the most often mentioned reasons for delaying the change of a business process is that the needed software changes take too much time. And this is almost inevitable unless the architecture of the software involved is well aligned to the business architecture. So, business agility requires close alignment of software architecture to business architecture.

Achieving this close alignment between software architecture and business architecture is what service-oriented architecture (SOA) is about. SOA is not a way to structure an application; it's a way to successively—over a number of years—structure the entire portfolio of business software.

Achieving SOA is not possible without enterprise architecture, business architecture, and software architecture (which is my preferred term for what IASA Sweden talks about as solution architecture). A vision of the electronically serviced enterprise is needed, and this vision should guide business architecture and software architecture so that every new solution becomes a piece in the enterprise architecture's puzzle.

To succeed with this alignment between software and business architecture, a lot of cooperation between the different roles are needed. This is especially true about the business and software architects. Business architecture is mostly about architecting the business, making it perform better than before. Software architecture is a lot about mapping business architecture to a business-oriented software solution. This requires, for most business architects, a higher level of software savvy, and for the software architect, a higher level of business savvy, than is often the case.

Anyway, this is where the challenge lies: How could we make business architects and software architects work better together, and how could we convince the agile development community that architecture is not just okay but a requirement for the development of an agile and competitive business? that there's no conflict between agile development and having an agile development project be restricted by architecture? and that there's no reason that software architecture can't be established in agile projects well before any coding takes place. If we who believe in business and software architecture can succeed in this, we have met this challenge, and there's a great future for business and software architecture. If we can't, I'm afraid many businesses will be less agile, and less competitive, than they could have been.

Pontus: Sten addresses the perennial goal of aligning business and IT. Whether we believe components, services, events, DSLs, MDAs, lean development, or whatever paradigm currently is espoused—indeed, even architecture and enterprise architecture itself—are essential to the future, pragmatic architects must be able to recognize the kernel in each approach and make them work toward the ultimate objective within the context of their own organizations. This emphasizes how important the ability to shift perspectives and to communicate always is to architects.

I would say the direct challenge to defining architect roles is the architects themselves. As a group, we tend to a wider scope and interest than is common, and as generalists we can find ourselves in any number of supporting roles that, while worthwhile from a business perspective, strictly speaking do not contribute to architecture in the sense we are after. However, we need to keep in mind that a role is a "hat, not a head"; the role describes our current engagement, not the totality of our interests and skills, and that, generally, we will have areas in which we are comparatively stronger. The roles provide focal points both for our engagements and employments, and for our career development.

While the role of the narrowly focused software architect may be a reality, in the long run, I believe all software architects should strive to encompass the objectives of the solution architect, blurring the line between the roles as described. Architectural guidance should come from below as well as from above, and who better to say in what ways technology is to be employed than the architect with the most direct hands-on experience?

I would also emphasize that architecture is by no means the exclusive domain of architects. Everyone involved in the development of a system or an organization contributes to its architecture and may possess some or even all of the architectural skills and mindset. Where the architect role contributes is in improving the consistency and efficacy of the resulting de facto architecture through taking direct responsibility for its qualities.

Conclusion

As we mentioned earlier, not all architect roles work only with IT. The final goal for an architect is to help improve the business, support its mission, and if possible innovate the business using IT to make the organization more competitive as a result.

IASA Sweden here presents one way of aligning business to IT by collaboration in distinct and clear architect roles, all working together with the same mission.

Resources

"No Silver Bullet: Essence and Accident in Software Engineering," F.P. Brooks, Proceedings of the IFIP Tenth World Computing Conference, pp. 1069-1076, 1986

Design for Manufacturability: Optimizing Cost, Quality and Time-to-Market, David M. Anderson (Second ed., CIM Press, 2001)

Enterprise Architecture as Strategy, Jeanne W. Ross, Peter Weill, and David C. Robertson (Harvard Business School Press, ISBN: 1-59139-839-4)

IASA

http://www.iasahome.org

2xSundblad Online Architect Academy

http://www.2xsundblad.com

 

About the author

Daniel Akenine is a chapter president at IASA and an architect evangelist at Microsoft Corporation. He has a history as a physicist and researcher in neuroscience before he joined the IT industry 10 years ago. He is the cofounder of two R&D companies, and holds patent applications in applied cryptography in the U.S. and Europe. During the last 10 years, Daniel has been working as a developer, senior architect, and CIO before he joined Microsoft in 2004.

 

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.