Business Improvement Through Better Software Architecture
by Sten and Per Sundblad
Summary: Business software is often challenged. According to studies performed by companies such as the Gartner Group, the Standish Group, and IDC, an astonishingly large portion of development projects fail to come up with anything useful at all. An even larger portion is challenged for reasons such as not supporting the business as well as the business needs to be supported. When businesses need to change fast to keep up with customer needs and with competition, software is often mentioned as the show stopper; the software used is often too complex and too unrelated to the business to allow the business to change as fast as necessary.
This article suggests that software architects must improve their business understanding to help solve this problem. But business people must also learn how to better communicate to software development teams what they expect from them. New architect roles, both on the business side and on the IT side, are needed for the creation of IT systems that solve business problems well, and that also help the business to be agile, able to change at least as fast as its main competitors.
Business software exists for one reason only: to support the business and its activities, or to help change the way business is performed. There's no other reason for business software. If it doesn't support the business the way the business needs to be supported or help change the business, it doesn't matter how technically brilliant the software is. Its value lies in its capability to increase the productivity and efficiency of the business.
In principle, there are three ways in which business software can support a business and its activities:
- A business process improvement project is started to improve the functionality of a specific business process. New or improved software is designed to help improve the way people can perform the business process.
- New ways to use technologies become available, making it possible to totally change the way business is performed. For example, Web services have profoundly changed the way a Web shop might interact with suppliers of goods sold by the Web shop. "Web 2.0" might have a similar effect on the way some businesses organize their interaction with customers and partners.
- Decision support.
As members of the huge software development community, we sometimes forget the real purpose of business software. We tend to admire IT solutions for their technical excellence rather than for the way they support the business. It's sometimes taken for granted that the software does its job.
What Business Managers Say
The Agile Business Thrives
Software Architecture in General
Extended Version of This Article
About the Authors
What Business Managers Say
A fairly recent study about business managers' top priorities for future IT investments, made by IDC , indicates that it's not always so. The survey was reported in Computer Sweden—the leading Swedish newspaper dedicated to IT—early in 2005. The article was written by IDC Nordic employee Per Andersen.
According to the survey, the highest priority (36.2 percent) was for "programs and services to be better integrated with business processes." The second-highest priority (35.2 percent) was for "better access to relevant information." Priorities such as "lower system cost" and "improved IT security" wound up lower on the list, with 26.1 percent and 23.4 percent, respectively.
This indicates that we in IT don't succeed particularly well in meeting business managers' needs. If we did, lower system cost and improved IT security would be a higher priority for business managers than better integration with business processes and better access to relevant information.
A Gap to Bridge
The figures also indicate that there's a gap between what concerns business managers and IT people. Business managers want effective business processes to help them achieve high-order business goals. They want access to information that helps them know whether the processes are as effective as they should be, and whether they are on the way toward achieving their business goals. Apparently, as seen from the IDC survey, these seem not to be equally high on the IT person's priority list.
The Agile Business Thrives
For business managers it's important that the structure of software solutions is based on the strategy and structure of the business. Otherwise, the business can't change swiftly enough when new business conditions require change. Being able to change quickly is an important characteristic for any modern business.
In contrast, if the business software is structured the same way as the business is, it becomes easier and less risky to change the software concurrent with the changes in business. When this is the case, the business becomes agile. The agile business always beats the less-agile competitor in the long run.
However, if the business itself isn't well structured, or if the structure isn't well known and understood, it's impossible to create a software structure based on the structure of the business. And if the software architect is much more interested and competent in technical issues than in business matters, which is often the case, it becomes really difficult to design software that is well aligned with the business.
Software Architects Need Business Savvy
Whenever you meet someone who is thought of as a software architect, chances are that this person is highly competent in technical IT matters—especially those that concern software—and has a high level of interest in these matters. It's less common that such a person is equally competent in business matters.
This might be a problem! For someone to be able to create a structure that supports the business well, that someone must first understand the business, its structure, its goals, and its problems. How else would it be possible to find the "right" technical solution?
We firmly believe that this should be one of a software architect's most important qualifications: to understand business issues well enough to be able to define IT solutions that help solve business problems, help reach business goals, and are structured in compliance with the structure of the business.
Businesspeople Don't Understand IT Well Enough
Now let's assume that the IT community sometime in the future arrives at a point where software architects indeed do understand business well enough to design effective business software. Would we, at that time, have solved the problem of software not quite being based on the way business is performed, not quite helping solve business problems, and not quite being able to help reach business goals? Not necessarily. There's another side of the coin, too. Businesspeople don't understand IT well enough to specify their requirements for business software, or to understand how innovative software could change the basics of their businesses.
This leads to an interesting question: Could it be that we need other kinds of architect roles to produce business software than those we typically think of today? And could it be that these roles differ more from each other than most of us think? We suggest that this is the case.
Five Architect Roles
We believe that Figure 1 gives a good view of the architect roles needed for the development of good business software. The rest of this article explains the responsibilities of each role in some detail.
Figure 1. Architect roles in business-software development (modified)
Roles, Not People
Remember that each rectangle in Figure 1 represents a role people can play, rather than a specific person. In reality, some roles will be played by a single person, while others will be played by multiple persons. More importantly, some persons will play multiple roles in relation to Figure 1, as well as in relation to roles not present in Figure 1.
We have never before thought of this role as an architect role, even if over the years we have talked a lot about the importance for software architecture of its outputs. It was John deVadoss, director of architecture strategy at Microsoft, who told us that he tends to talk about a strategic-architect role, the purpose of which is to change business focus and define the enterprise's to-be status. This role, he says, is about the long view and about forecasting.
Notice, though, that this role is about business strategy rather than IT strategy. The strategic architect works closely with top management, which is the body responsible for strategic decisions. The strategic architect might even be part of top management.
Years ago, Peter Drucker told us all that every organization—be it a commercial business or a public organization—has a purpose and a mission. The purpose describes why the organization has been started and why it still exists. In the case of a commercial business, Drucker says, the purpose is always to create economic values for its owners. The mission describes what the organization is supposed to do for whom; it should be expressed in terms of customer values rather than in concrete products to provide.
Future Product and Market Scope
A strategic plan should tell a business what markets it should get into and what kinds of products it should offer those markets. Such a specification of the future product and market scope then drives other strategic decisions. For example, it drives decisions about which key capabilities are required to support the future product and market scope, decisions about size/growth and return/profit guidelines, business unit missions, business processes and activities needed, and more. The strategic plan should also tell what the business must do to get out of some activities to make room for the new, and when all that work must take place.
Based on the strategic plan, key people and resources must be allocated to do the necessary work, and goals must be set to direct that work. Every business process and every business activity must have a purpose, and that purpose must be to produce business values, contributing to the value streams.
To define, negotiate, and document all of this is the business-strategy architect's job. It's also the job of the business-strategy architect to communicate all of it to top management, for approval.
As already noted, the mission of business architects is to improve the functionality of the business. Their job isn't to architect software but to architect the business itself and the way it is run. However, the structures they provide should be used by software architects as a foundation for the design of business software solutions.
The Business Architect Association defines the term business architect as follows:
A Business Architect is anyone who takes a step back, looks at the way work is being directed and accomplished, and identifies, designs, and oversees the implementation of improvements that are harmonious with the nature and strategy of the organization.
The Open Process Framework defines business architect as "the specialized architect role played when a person develops the architecture for a customer organization's business enterprise." The framework also mentions a number of areas in which a business architect needs expertise. Among them you'll find such areas as:
- Deep knowledge of business and strategic marketing.
- Strong in strategic and analytical thinking.
- Excellent communication and presentation skills.
- Solid experience in areas such as business, marketing, and business-process reengineering.
Notice that no IT-related areas of expertise are mentioned. This strengthens the argument about business architecture being primarily about business improvement and only secondarily about creating a foundation for software development.
Existing Business-Architecture Methodologies
Formal methodologies for business architecture exist. If you're interested in finding out which some of them are, you could take a look at an extended version of this article, which is published here.
Multiple Levels of Abstraction
Business architecture is work that spans multiple levels of abstraction. It's not enough to map the activities of business processes; the external profile of each process and activity must also be analyzed and documented. The business architect must understand how even low-level activities contribute to the business's value streams. Also, the business architect must be able to evaluate each activity in terms of how important it is to the organization's results, how well it needs to perform versus how well it actually does perform, and whether it helps differentiate the enterprise from its competitors.
Software Architecture in General
When moving the focus from business architecture to software architecture, it's easy to see how different they are. Business architecture is about architecting the business; software architecture is about architecting software meant to support, automate, or even totally change the business and the business architecture.
They have much to do with one another. Software architecture should be based on business architecture. How else could IT systems effectively support the business? Inversely, business architecture should be designed to take as much and as effective advantage of information technology as possible. The two go hand in hand, but they are different.
In our framework (see Figure 1), we have included one software-architect role only. It's the solution-architect role.
Solution architect is a relatively new term, and it should refer also to an equally new concept. Sometimes, however, it doesn't; it tends to be used as a synonym for application architect.
If we talk about the service-oriented world as the new world, and everything that came before SOA as the old world, it could be argued that the concept of "an end-to-end application" belongs to the old world. We believe that the most common conception of an application is a computer program that contains everything needed to help solve a business problem. User interface, business logic, and data-access logic are typically included in an application. Sometimes, the database is also included.
In an application-centric world, each application is created to solve a specific business problem, or a specific set of business problems. All parts of the application are tightly knit together, each integral part being owned by the application. An application architect designs the structure of the entire application, a job that's rather technical in nature. Typically, the application architect doesn't create, or even help create, the application requirements; other people, often called business analysts, less technically and more business-oriented than the typical application architect, do that.
Service-Oriented Solutions Are Different
In SOA, it's different. IT solutions to business problems tend to be solved by the use of multiple autonomous services, where none of the services is an integral part of or owned by the solution. Instead, the services are only used by the solution, just as they might be used by other solutions.
For example, as seen in Figure 2, a product service might be used by a sales system, by a purchase system, by a product-development system, by a warehouse system, and probably by other systems, too. The service will not be owned by any of these systems; it will be a separate resource used by each of them. It will contain some functionality that is developed for the sales system, some that's for the purchase system, some for the warehouse system, and perhaps some for general use.
Figure 2. Reuse of product service
One of the four tenets of service orientation is for services to have clear and respected borders. The internals of a service should be used by that service only. According to this tenet, the only way for a service consumer to enjoy results produced by the service is to send a message to it, asking it to perform some operation. There's no way the consumer will be let inside the service's outer border.
It's obvious, then, that the service must expose the functionality it offers through service interfaces. The typical service interface today seems to be a Web service. Consider a service such as the product service mentioned earlier. It will serve different systems with different needs. Doesn't it seem reasonable that each need will be taken care of by a separate service interface, as in Figure 3—one for the needs of the sales system, another for the needs of the purchase system, and so on?
Figure 3. Separate Web service interface for each conversation (Click on the picture for a larger image)
It follows that consumers of such a service can experience the service only through its service interface. In effect, for a consumer, the service interface exposed to that consumer is the service.
Business-Driven Solution Architecture
For a service to be successful, it must meet its consumers' needs. From this it follows that consumption needs should drive the specification of the service's interface (or interfaces). For each detail of the service's set of interfaces, an identifiable business need should exist.
It follows from the job title that a solution architect should architect technically oriented solutions to business problems. If this means—in a service-oriented environment—to design service interfaces, it's interesting to note that the job isn't terribly technical. It requires technical understanding, but to an equally high degree it requires understanding of business issues and business needs. This is probably not a profile that very well matches the profile of most of today's application architects.
Context-Aware Solution Architecture: Creating the Physical Order of a Business
Christopher Alexander, the man behind the design pattern movement, says another interesting thing about architecture in general: "The activity we call building creates the physical order of the world, constantly, unendingly, day after day … Our world is dominated by the order we create." As a consequence, whatever we build is always part of a greater whole, and as architects we can't just focus on what we build but also on how well it harmonizes with its present, or at least its future, environment. Alexander is a "traditional" architect; his environment consists of "towns, buildings, and constructions," but what he says is equally valid for the architecture and building of business systems.
This quality of a design fitting well with its present and future environments is crucial for service-oriented architectures. It's our absolute conviction that the most important purpose for service-oriented architectures is the business agility they're capable of bringing to the enterprise. And being agile is a required—even if hard to achieve—attribute of any modern business. It's much more important for a business as such to be agile than for the software it uses to be produced by agile development methods. There's not necessarily any conflict between the two, but business agility is by far the most important one.
In the last part of this article, we'll talk about the enterprise architect and that person's vision of the electronic or serviced enterprise. Such a vision is realized step by step over many years, by architecting and implementing increasingly effective business processes and effective technical solutions to support them. If the solution, business, and enterprise architects work well together, they can make sure that every single solution fits well into the enterprise architect's vision of the enterprise's future business process and system portfolio.
Thus, each new or improved business process, and each new or improved IT solution, becomes an important part of the greater whole. This is the way the physical order of the enterprise is constantly and coherently re-created and improved.
If, in contrast, the solution architect is allowed—or even forced—to sub-optimize solutions, the business will never be agile. It won't be able to change with the same speed as its more-agile competitors.
One might ask how a solution architect can be forced to sub-optimize a solution. Unfortunately, this happens all the time. Building the serviced enterprise is a process that takes time and money, and every project involved becomes more expensive and takes more time to plan and implement because of that. This is especially true for the first few projects during that process. Extra money and extra time must be allocated to every project to avoid sub-optimization. When no extras are allocated, the solution architect is in effect forced to sub-optimize the solution. It might seem hard to swallow, but in the long run sub-optimization costs much more than the extra cost needed to avoid it.
An Infrastructure of Information
Notice that we're not advocating top-down architecture or top-down development of either business or business software. To the contrary, what we do recommend is a top-down effort to make sure that business and software architecture support business strategy and strategic plans, and also to make plans for an infrastructure of at least such information that should be shared within the enterprise across organizational borders.
Such an infrastructure could be compared to the infrastructure of electricity and the infrastructure of water, which are available to make life easier for the builder of houses in a typical city. To be shareable across organizational and functional borders, the infrastructure must be planned in a top-down fashion. But design, implementation, deployment, and enhancements over time will all be performed bottom-up.
You can envision the whole from a top-down perspective, but it will grow from its parts! The "whole" grows organically from the needs of real people rather than from a grand master plan, even though it's conceptualized from a top-down perspective. To paraphrase Alexander, each business process we design or modify, each service or user application we define, develop, deploy, modify, and enhance will all help create the physical order of our business, constantly, unendingly, day after day.
This role isn't directly involved in software development, so we're not talking much about it in this article. The technical infrastructure exists for deployment of the solutions of the solution architect, which means that the solution architect and the technical infrastructure architect should work together to ensure safe and productive deployment and operation of the system.
Notice that our name for the role—just slightly different from what's common—emphasizes that it's about technical infrastructure. This involves things such as hardware, network, operating system, and system software. The technical infrastructure does not involve any business software. Having said that, it could involve the so-called infrastructure services, such as a security service, a logging service, or an error-management service.
We'll discuss the enterprise architect role last. This is for a good reason. The enterprise architect role collects all of the other architect roles—with the business strategy architect role as the only exception—within it. You could argue that enterprise architecture consists of business architecture, solution architecture, and technical infrastructure architecture. You could also argue that additional architecture roles could be included; security architecture and organization architecture are two good examples.
It all depends on how you define enterprise architecture. Let's see how some sources define it, and then talk more about the role and its responsibilities as we see them.
Wikipedia defines enterprise architecture as follows:
Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational subunits, so that they align with the organization's core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, and process architecture as well.
The U.S. Department of Health and Human Services, in its Centers for Medicare & Medicaid Services, refers to the Clinger-Cohen Act, which requires that every U.S. federal agency develop an enterprise architecture. Enterprise architecture is defined as "a management engineering discipline presenting a comprehensive view of the enterprise, including strategic planning, organizational development, relationship management, business process improvement, information and knowledge management, and operations." Enterprise architecture is also described as consisting of "models, diagrams, tables, and narrative, which together translate the complexities of the agency into simplified yet meaningful representations of how the agency operates (and intends to operate)."
What Do We Need Enterprise Architects For?
The enterprise architect should concentrate on the big picture, rather than on low-level issues. For example, the enterprise architect should know that there is a purchasing business process, what this process is for, and how it relates to business's value streams, but the enterprise architect doesn't necessarily have to know which business activities that process consists of.
The enterprise architect should also know about the possible existence of a purchasing process service supporting the purchasing process. Even more important, the enterprise architect should know about the existence of all entity services, and all business process services, and also what the mission and responsibilities are for each service. But the architect shouldn't be too much concerned about what interfaces each service exposes, or about its internal contents or structure. These details should be left to the solution architect and software engineers, and to the owner of the service.
Many large companies do employ enterprise architects. Some are called enterprise architects, while others have different titles, such as chief information officer (CIO). In the latter cases, the CIO takes on enterprise architect tasks in addition to other CIO tasks. As you can see from Figure 1, the enterprise-architect's place is between the business-strategy architect and the other architects. The enterprise architect is controlled and led by business strategy, and should control and lead business, solution, and technical-infrastructure architecture efforts. Also, the enterprise architect should own and care for the "city plan," which is a large-scale map of the business architecture and the IT resources used to support the business. Chiefly, such a map would consist of overview models, lists of items, tables, and narratives. Here are a few examples of lists and tables that might be included in a city plan:
- List of business processes
- List of strategic information areas
- Cross-referencing table of interactions between business processes and information areas
- List of available applications and services
- Cross-references of applications and services to business processes and information areas
- Cross-references between applications and services
Each list and table item should be populated with or supported by quality information. For example, how well do we need this application, service, or business process to perform, and how well does it actually perform? An item with mediocre performance is a problem if we need it to perform well or excellently, but if mediocre is good enough, its actual performance is not a problem.
Business-Improvement and Software-Development Efforts
In principle, all development of business software should be based on the enterprise architect's strategic road map leading toward a future desired state. It's the enterprise architect's job to know where development efforts can yield the highest payoff for the efforts needed. It's also the enterprise architect's job to know where the fruit is hanging low and will be easy to pick.
Notice that new business software should never be the goal for business improvement efforts. Instead, the goal should always be improved business value streams in terms of things such as higher value for internal or external customers, lower costs, or faster throughput. The business software is always just a means to that end.
Therefore, business-software development should always start with a detailed business analysis performed by a business architect. Some combination of the enterprise architect, the strategy architect, and top management sets the scope for such analysis, typically tied to a business process.
The business architect is constrained by this scope and by an overview model of business processes that has been created from a top-down perspective. Within these constraints, the business architect performs a detailed analysis of the business process at hand, from a bottom-up perspective. Together with a solution architect, the business architect designs a model of the future state of that part of the business. After approval, this model is handed over to the solution architect for design of a technical solution.
Notice again how top-down and bottom-up perspectives go hand in hand to create the best results in a minimum amount of time. Also, notice how this process highlights the position of the enterprise architect between the business strategy architect and the business and solution architects.
This position, and the fact that the enterprise architect owns all the business and technology models, makes it possible for the enterprise architect to give strategic directions, as well as business and technology context, to each business improvement and software development effort.
Business managers want IT systems that are better integrated with their business processes and that give them better access to relevant business information than the IT systems they have traditionally been given. Managers set higher priorities for these qualities than for lower system cost or improved IT security. This should tell us that IT doesn't satisfy business managers the way business managers need to be satisfied. It should also tell us that there are great opportunities for increased business agility, increased competitiveness, and improved business functionality if we could solve this problem and satisfy business managers better.
The main reason for these difficulties seems to be the gap in knowledge, understanding, and interest between businesspeople and IT people. This gap results in too-large differences between the architecture of the business and the architecture of its software. When these architectures are not well aligned, it's difficult to make the software revisions needed to change and improve the business processes.
If an enterprise could bridge that gap, or even close it, and if it could better align its software architecture with its business architecture, that enterprise would become more agile; it would be better able to change when external pressure makes change desirable for the business. Today more than ever, an agile business thrives and is better able to compete in the marketplace than a less-agile business.
Business architecture should be established and managed by a new breed of business architects rather than by the old business analysts. Software architecture should be established and managed by solution architects with a more business-oriented and a less technical background than yesterday's application architects. Business and solution architects should work together to design and suggest improved business processes that take better advantage of technical opportunities than the original ones did.
Extended Version of This Article
If you enjoyed reading this article, you might also enjoy reading the extended version, which we have published on http://www.2xsundblad.com/en/articles/business_improvement_through_better_architected_software. It's more than twice the size of this one, and it covers some other interesting aspects of development roles. For example, it suggests a very clear border between solution architecture and software engineering.
IDC presents itself as "the premier global provider of market intelligence, advisory services, and events for the information technology, telecommunications, and consumer technology markets." You'll find it at http://idc.com.
For example, Peter Drucker's Management: Tasks, Responsibilities, Practices. Collins (reprint edition April 1993). ISBN 0887306152. Several other Drucker titles exist, all of them very interesting. Five people reviewed this title on Amazon.com; all five gave five stars to the book. You may also want to check out Christopher Alexander's The Phenomenon of Life: The Nature of Order, Book 1 (Prologue). Center for Environmental Structure. ISBN 0972652914.
The following Web sites are also good references:
About the Authors
Sten Sundblad is cofounder and chief solution architect of Sundblad & Sundblad, a company he runs with his son, Per Sundblad. The main business of Sundblad & Sundblad is to develop and use training material to train software architects. Sten is a frequent speaker on architect subjects. Sten is also a Microsoft regional director and was selected in 1998 as the first non-U.S. Microsoft Regional Director of the Year. He was named a Microsoft MVP Solutions Architect in 2005 and 2006. Sten lives in Uppsala, Sweden.
Per Sundblad is cofounder and managing director, as well as solution architect and software engineer, of Sundblad & Sundblad, a company he runs with his father, Sten Sundblad. The main business of Sundblad & Sundblad is to develop and use training material to train software architects. Per has also been a Microsoft regional director since 1997. He was named a Microsoft MVP Solutions Architect in 2005 and 2006. Per lives in Uppsala, Sweden.
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 website.