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 ITarchitects. We then describe a study undertaken by IASA Sweden to betterunderstand IT architecture, which entailed a process of mapping the artifactsproduced by architects at different levels in an organization. Finally, wediscuss 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 relativelynew compared to other professions and the associated responsibilities have beenevolving over the past decades. This is not surprising as the use of IT andsoftware has changed continuously since computers and IT systems wereintroduced. IT and software have been integrated into many people'slives, and technology is easier to consume and use than ever before. Does thatmean 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, producingnew software solutions gets easier and faster. You can create an advancedSOAP-based service in less than a minute. On the opposite side, however, thefundamental architecture of these solutions is more complex than it used tobe. Why? Well the simple answer is because we expect much more fromtoday'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 talkingto me. I was amazed. Obviously, I had heard of mobile phones previously, but Inever had actually spoken to somebody using one. Not so many years later, amobile phone is an integrated part of my life. The technology does notamaze me anymore; on the contrary I get very annoyed when the technology doesnot perform as I expect it to. Traveling by train in a tunnel, I still expectthe 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 softwareworks.

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

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

We Need Architects to Deal with Complexity

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

Accidental complexity is different; it springs from thetechnological and architectural choices made while solving the problem. Forexample, how much flexibility for change should the solution have? Decisions onarchitectural qualities, such as manageability, scalability, security, andreusability, must be made with input from multiple stakeholders whose needs maybe at odds. These decisions determine the accidental complexity, andbalancing 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 frequentlyheard. However, has the correlation been proven? Certainly, bad architecture canmake a business inflexible and slow to act. Many large organizations haveinvested in IT for many decades now. In the last 10 years, investments in IThave been driven largely by the shockwaves from the Internet revolution, arevolution that has changed the way organizations interact with theircustomers—generating new types of information in documents, e-mail, portals,and so on. However, many of these investments were made with little care to anyenterprise-wide strategy or architecture, and some organizations now refer tothe 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 processesor business capabilities is getting out of proportion. To make small changes inthe business model or process takes so long or costs so much that they arejust not done. This is an example of when IT is bad for business agility; inthe end, we need to fix that. Who is better suited to fix that than anarchitect?

We Need Architects to Reduce the Cost of IT

As others such as David Anderson have written, the cost ofmanaging your existing IT is often as high as 70-80percent of your total IT budget. More often than not, projects under timepressure result in decisions which multiply life-cycle costs during operationsand maintenance. Disparate solution designs and technologies from differentprojects drive total costs and dilute skill sets. Complex and unknowninterdependencies lead to unexpected consequences and costs. Architects canmake a real difference in cost reduction; by architecting quality solutions formanageability and supportability.

We Need Architects for Better Business Alignment

In the early days, we used IT primarily to automate manualprocesses. We used IT to lower costs on information transactions and to storeand query data in ways that had not been possible previously. However, thosequick wins will someday come to an end. Some organizations have already used ITvery effectively to automate and support their business processes, and now theywant to move on. It is time to do more sophisticated IT investments alignedwith the business strategy and actually use IT to differentiate a company fromits competitors.

We need architects to create long-term and short-termstrategies 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 playthe same role in every project or company. What kinds of roles should theyplay, and how can they work with other architects and team members effectively?What we need is a framework for delivering new IT capabilities that supportsand improves the current business model, in which different kinds of architectscan work together in a consistent way.

The first problem you encounter when you start discussingdifferent roles is the number of perspectives and roles out there. IASA foundmore than 50 different roles: Although many roles were more or less equivalent,many organizations have created their own roles with unique deliverables. Thiscauses 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, andhave a career in the profession when the roles are so murky?

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

The group found approximately 40 different artifacts thatcould be agreed upon. The next step was to map those artifacts into threedifferent levels in an organization to see if they would form some kind ofnatural 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 asimple way; an architect role can operate on several levels. As an example, anenterprise architect can work on both high-level policies as well as technologypolices if they are considered to be important for the whole organization.

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

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

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

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

Architect Roles

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

Enterprise Architect

Typical artifacts include: IT strategies, capabilitymaps, city plans, integration strategies, as-is/to-be analysis, architecturalprinciples, gap analysis, life-cycle analysis, application portfoliostrategies.

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

The role oftenreports to a CIO or to a chief architect. An enterprise architect ownsstrategies at several different levels in the organization—from standardsthat have a global impact on the organization to strategies regarding thingssuch as security or infrastructure.

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

The use of enterprise architecture is still immature in mostorganizations. As IT departments evolve and become more closely aligned withthe business departments, we expect the profession to mature and become clearerover the years to come. We believe that growth in tooling and evidenced-basedbest practice from the scientific community will also influence thisprofession.

Competence: Deep knowledge in both business and IT;leadership and negotiation skills; experience in governance, project managementand 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 tothe business and understand in detail how the organization works. They areactive in modeling processes in the organization and support solutionarchitects with analysis and requirements on new or existing solutions. Theyunderstand how the IT systems support the business and suggest improvementstogether with enterprise architects. Business architects are active in ongoingprojects in the organization using their influence to ensure that projectsdeliver benefits to the business in an optimal way.

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

Competence: Deep knowledge in the business; processmodeling; 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 thedesign of IT solutions based on requirements from the business, making use ofexisting IT capabilities and services in the organization.

Solution architects have a special responsibility to reuseexisting functions and services. They align new solutions to the currentarchitectural principles regarding standards and integration in theorganization. They balance the functional and nonfunctional requirements withnecessary prioritizations and compromises. The goal for the solution architectis the success of the current project, in addition to how well the projectaligns to the architectural principles and how well it reuses existingcapabilities.

When organizations move from traditional applications tointegrated solutions and services, the role of the solution architect becomesmore and more important. The role of the solution architect is clearer inlarger projects, particularly when many systems are involved. If the project issmall or the application is isolated, this role may not be necessary in theparticular project.

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

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

Software Architect

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

Description: A software architect works with thestructure and design of software systems. Software architects work with bothfunctional requirements as well as different architectural quality attributessuch as flexibility, performance, reusability, testability, and usability. Somequality attributes obviously may be shared with the solution architect. Theyprioritize and optimize the different quality attributes with respect to costand other constraints. The focus for the software architect is primarily thecurrent project, whereas the solution architect has a wider focus to reuseexisting assets, policies and regulations, although this could apply to thesoftware architect as well if the organization finds it necessary to havestrict guidance in place for software development.

The role of the software architect becomes more and moreimportant 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 forwardsome of the challenges concerning the roles for architects. For this, we turnedto Sten Sundblad, chiefarchitect at Sundblad & Sundblad,and Pontus Gagge, an enterprise architect at Sandvik Corp., to ask them what they think are the biggestchallenges.

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

When a business is challenged from the outside, it oftenneeds to change parts of its business strategy. Almost without exception, thismeans that it has to change its business architecture (meaning its businessprocesses), too.

One of the most often mentioned reasons for delaying thechange of a business process is that the needed software changes take too muchtime. And this is almost inevitable unless the architecture of the softwareinvolved is well aligned to the business architecture. So, business agilityrequires close alignment of software architecture to business architecture.

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

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

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

Anyway, this is where the challenge lies: How could wemake business architects and software architects work better together, and howcould we convince the agile development community that architecture is not justokay but a requirement for the development of an agile and competitivebusiness? that there's no conflict between agiledevelopment and having an agile development project be restricted byarchitecture? and that there's no reason that softwarearchitecture can't be established in agile projects well before any codingtakes place. If we who believe in business and software architecture cansucceed in this, we have met this challenge, and there's a greatfuture for business and software architecture. If we can't, I'm afraidmany businesses will be less agile, and less competitive, than they could havebeen.

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

I would say the direct challenge to defining architectroles is the architects themselves. As a group, we tend to a wider scope andinterest than is common, and as generalists we can find ourselves in any numberof 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 roledescribes our current engagement, not the totality of our interests and skills,and that, generally, we will have areas in which we are comparatively stronger. Theroles provide focal points both for our engagements and employments, and forour career development.

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

I would also emphasize that architecture is by no meansthe exclusive domain of architects. Everyone involved in the development of asystem or an organization contributes to its architecture and may possess someor even all of the architectural skills and mindset. Where the architect rolecontributes is in improving the consistency and efficacy of the resulting defacto architecture through taking direct responsibility for its qualities.

Conclusion

As we mentioned earlier, not all architect roles work onlywith 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 theorganization more competitive as a result.

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

Resources

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

Design for Manufacturability: Optimizing Cost, Qualityand 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 chapterpresident at IASA and an architect evangelist at Microsoft Corporation. He has a history asa physicist and researcher in neuroscience before he joined the IT industry 10years ago. He is the cofounder of two R&D companies, and holds patentapplications in applied cryptography in the U.S. and Europe. During the last 10years, Daniel has been working as a developer, senior architect, and CIO beforehe joined Microsoft in 2004.

This articlewas published in the Architecture Journal, a print and online publicationproduced by Microsoft. For more articles from this publication, please visitthe Architecture Journal Web site.