The Business of Software Architecture – Part 1

Delivering Sound Software Architectures Consistently: Who do you need?

By Jim Fisher

Introduction
The role of the Software Architect in consistently delivering sound software solutions equals
that of the Building Architect who designs and oversees the construction of the most
sophisticated buildings. It is both a science and an art at the same time; good software
engineering practices dictate the use of a software development methodology and the
architect must take into account the “fuzzy” desires and aspirations of the business
stakeholder to solve business problems.

Poor software architecture can be a significant obstacle to an organization seeking a

sustainable competitive advantage. Operational dysfunction, lost revenue, and increased
business risk can result from the failure to design and deliver well constructed and
compatible software solutions. However, the ability to deliver solutions can be an enabler
for increased business agility, reduced IT costs, and improved software quality.

However, something is regularly overlooked in the translation from “fuzzy” requirements to

production deployment. For example, systems with software architectures that do not
properly separate concerns, inefficient development processes, or poor enterprise
integration strategies are typical challenges faced by modern IT organizations, which lead to
missed opportunities and failure to meet business objectives.

To address these issues, an architecture practice is needed to govern and direct the
structure of software systems that an organization has attained to support its business
operations. The plan and roadmap for creating such a practice will be described by
answering these three questions:

• Who do you need and what skills must they have?

• What are they going to do?
• How are they going to do it?

The first question of answering “Who is needed” will be addressed in this paper.

Who can consistently deliver sound software architectures?

The building-computer system analogy, coined by Christopher Alexander, is useful because
it communicates the idea of structure in process and output but one that is adaptable to the
needs of the stakeholder. In Alexander's seminal work “A Pattern Language: Towns,
Buildings, Construction”, he described an architectural system that originated from the
observation that many medieval cities were attractive and harmonious. The rationale was
because they were built to local regulations that required specific features, but freed the
architect to adapt them to particular situations.1

This idea is evermore as relevant to the struggle between business and IT. There is no
doubt that software written with a sound software architecture is a good idea. But who
should be responsible for consistently delivering sound software architectures?

1
Christopher Alexander By: Wikipedia

1
Software Architect Dilemma
The word consistently implies the idea of enterprise standards in process and
implementation. These standards need to be enforced, governed and maintained. Often,
there is an architecture council that serves that purpose. But in a large organization with
several enterprise applications, there is a risk of creating an ivory tower2 of architects. In
this case, the council has been appointed to a position of leadership at the enterprise level,
but has no actual authority to enforce their directives. The organization becomes
fragmented with different departments realizing very distinct and incompatible software
architectures.

In addition, the word ‘sound’ enforces the need to hire experienced and seasoned software
engineers and developers. Unfortunately, in the software industry, as technologists become
more advanced, they also become more opinionated. In general, varied opinions are
beneficial because it shows they are thinking about solutions to problems from different
perspectives. However, in software architecture it can become very difficult to get seasoned
professionals moving in the same direction and following common practices.

The software architect dilemma is that the architect must conform to organizational
architecture standards yet at the same time address the needs of their constituents. The
problem arises in large organizations when multiple IT departments must collaborate in a
streamlined business process. To use the previous building analogy, floors continue to be
built on top of each other without giving sufficient consideration to common infrastructure
matters such as heating and air, electrical, and plumbing.

Organizational Pattern for Architecture Leadership

Architecture is the philosophy of software engineering. Every software architect comes to
the table with their own experiences and practices. Patterns must be established in order to
form some common ground amongst the architects. In general, patterns are approaches to
solving problems that in the end produce favorable results.

This paper presents a special kind of pattern called an organizational pattern, which
presents a management technique or organizational structure, to help solve the described
software architect dilemma. The purpose of this Organizational Pattern for Architecture
Leadership is to define the roles within the software architecture domain so that tasks and
activities can be defined for ultimately achieving business goals. In other words, this
pattern will define who is needed for consistently delivering sound software architectures.

Within a large enterprise, there are four software architecture roles which must be fulfilled.
In some organizations, the same person may have to wear different hats, which are distinct
variations of the architect role within the organization that should be clearly defined. These
roles are:

• Business Architect
• Enterprise Architect
• Application Architect
• Solution Architect

2
Ivory Tower By: Wikipedia

2
Before getting into the various software architecture roles, it is important to define the
qualities common to software architects.

Common Qualities of a Software Architect

Since it is the social aspects of the software architect that sets them apart from the more
generic technologist, much of the qualities involve the soft skills. Briefly, these qualities
are: servant-leadership, broad understanding of technology, strong interpersonal skills, and
a strategic outlook that aligns business goals with technology.

Servant-Leader
Essentially, the role of an architect is to be a “servant-leader”. They need to be culture
builders that reach out to the ideas of others. Their nature is to be inclusive of the talent
that is often buried within an organization.

The servant-leader does not engage the organization from a throne in an ivory tower, but is
instead willing to roll up their sleeves and get involved in the game of successfully achieving
business objectives through technology.

Avoiding the organizational ivory tower is largely a communication challenge within the
organization. It is a matter of trust that must be built between the architecture leadership,
the business community, and the rank and file within the IT organization. It is this servant-
leader quality that marks the beginning of an architect that can win people over to following
their direction.

Strong Interpersonal Skills

A software architect's ability to lead has much to do with the relationships they have built
with their followers. Demonstrating success in managing conflict and publicly showing
genuine encouragement with its team members, builds trust. It is this foundation of trust
from the leadership team that lays the groundwork for motivating the development staff to
deliver results.

Broad Understanding of Technology

A software architect must have both a deep and wide understanding of technology. The
software architect must understand the qualities of software that, when put together, form
a cohesive specification for a sound software architecture.

They must be able to discuss business strategy with a stakeholder and also converse with a
specialist without getting lost in the technical nomenclature. One moment, a software
architect may need to converse with a stakeholder about the relevance an architecturally
significant component (e.g. digital signatures or single sign-on) has to the success of their
enterprise or department, and in the next conversation, be directing a team of programmers
in best practices and design patterns as they apply to their application.

Strategic Outlook
A software architect’s decisions should be driven by and aligned with business goals instead
of technology preferences. It is often said that “the road to China is taken with many small
steps.” So it is with rolling out a software architecture at varying degrees within the
organization. The key is to begin taking the small steps in the right direction by always
maintaining a focus on the target environment.

Also, the software architect should avoid the trap of technology for the sake of technology.
[Software] architects are leaders and therefore must have a strong interest in and

3
understanding of the business, its strategic direction, dysfunctions, strengths, etc. It is not
good enough to be a superior technologist.3

Technologists often like to pontificate on the latest frameworks and design patterns that are
en vogue. However, in the real world, business qualities such as time and cost need to be
given more attention by modern software architects. Budget must always be kept in the
forefront or else the project comes to a halt. Therefore, mediocre time-to-market can
destroy an opportunity. More specifically, software architects need to apply a process that is
congruent with these essential business needs.

Articulate and Persuasive

Software architects must effectively communicate with others that reside within their
domain of influence. Therefore, it is essential that they articulate their ideas in a way that
moves knowledge workers to action.

It is important to seek the win-win positions/solutions on issues as architecture content is

developed. There are difficult decisions to be made. Emotions can impede progress.
Effective negotiation skills are invaluable for peacefully resolving situations with decisions
that benefit the organization.

Architect Roles
Each architect role sits somewhere along the Architect Business-Technology Continuum (see
Figure 1). The continuum has two extremes: Business and Technical. For example, the
Business Architect is more business focused whereas the Application and Solution architects
are more technical. The Enterprise Architect must take into account both ends of the
continuum. None of the roles should be so extreme and take a blind eye to other side of
the continuum. The point is to note the focus for a particular architect role. A skills matrix
has been provided in Appendix A for delineating how these skills map to a particular
architect role.

Figure 1: Architect Business-Technology Continuum

Another way to understand how the different architect roles relate is through an
organizational chart (see Figure 2). The Enterprise Architect sits at the top of the
architecture leadership hierarchy bridging both the business and technical aspects of the
enterprise. The purpose of this hierarchy is for provisioning the architectural governance
that must take place in software development.

3
Characteristics of an effective enterprise architect By: Scott Bittler

4
 Figure 2: Architect Leadership Hierarchy

Alternatively for context, Figure 3 demonstrates how the different architects fit into the
management structure of a typical organization.

Figure 3: Software Architect Roles in Execution

These roles are described in the following paragraphs at an increasing depth of technology.

5
Business Architect
The business architect is the most business directed role naturally because its focus is on
modeling the structure of the business (i.e. business domain concepts and process). They
are more concerned with what / how things get defined, and less with how they are
implemented. The business architect is similar to the enterprise architect, only with a more
specialized focus on a particular business domain within the organization and with less
attention to the information technology solution.

However, business architects are concerned about technology. The difference is that their
technology is manifest in business terms instead of computer jargon. But it is still
technology because their work products are used to produce business value. For instance, a
highly sophisticated business process or method that enables an organization to be more
efficient than any other competitor gives that organization a competitive advantage. That
proprietary process or method is still a technology!

The business architect understands the system boundaries of the application being
developed and the overall placement within the enterprise. More specifically, the Business
Architect must guide the phasing of application deployment based on business needs and
dependencies with other interacting applications in the business workflow.

Business architects will often interact with the system users, stakeholders, project
managers, and directors. Therefore their social skills and vocabulary must be sufficiently
refined to maintain a level of respect with these individuals.

Enterprise Architect
The enterprise architect is similar to the business architect in that their focus is on achieving
business goals and objectives. The primary difference is their scope of influence, which is
across the entire organization (including IT) and even the external environment. In other
words, the enterprise architect has coverage over what the business is doing and how the
organization is performing for its customers.

This role must accommodate the concerns of high level officers and business leaders within
an organization (i.e. C-level, president, vice presidents, etc.). Terms such as governance,
standards, and Key Performance Indicators (KPI) are commonly used words in their
vocabulary.

The enterprise architect must take a holistic view of the organization that unites business
and technology concerns into a strategic enterprise vision. Their work products provide a
bridge between business and IT by considering the business plan and producing an IT
architecture that is viable yet aligned with the corresponding business goals.

The Importance of Strategy and Vision

One danger the enterprise architect must stay aware of is setting a course of action that is
technically not feasible. Since the enterprise architect works from a high level, variations in
their strategy can have significantly different outcomes in realizing the solution. At this
level, there is a fine line between applying strategy and tactics. It is important for the
enterprise architect to stay strategic.

It can take many years for an enterprise to reach maturity. Standards will leap frog each
other several times. The job of the enterprise architect is much more than setting the
course for IT with standards du jour. Instead, the enterprise architect must be able to

6
telescope their vision to best direct their business and solution architects towards an
effective enterprise.

Application Architect
The application architect is the most tactical of all the software architect roles. Their
primary function is to ensure system modules successfully reach production. While this role
is the most tactically oriented, all the qualities of leadership still apply within their domain of
influence. For instance, an application architect has jurisdiction of the development
practices that take place in seeing that module into production.

The application architect needs to ensure compliance of development guidelines, patterns,

and practices for the team they are leading. When situations arise which may require a
change in development process, it is the application architect's job to communicate that
issue to the team lead or project manager to ensure proper governance of the issue.

On small to medium sized projects, the application architect may also wear the hat of “team
lead” as it is commonly called. However, the team lead role is distinct from the application
architect role. The team lead position is more focused on the project management concerns
and making sure the team is on track at a functional level. The application architect on the
other hand, is more aware of the science of application development at the business
component level. For instance, an application architect should be aware of and avoid
circular dependencies between the components of an application. Alternatively, the team
lead is more akin to a project manager, albeit at a subsystem level.

Solution Architect
The solution architect is the most technically oriented role within the enterprise. They
typically are assigned to the development of multiple applications and the most significant
and challenging high-risk tasks needed to develop those applications.

The primary solution architect concerns are:

z Qualities of Software
z Software Development Process
z Incorporation of Software Frameworks
z Software Tool Integration

Qualities of Software
The solution architect must ensure qualities of software are taken into careful consideration
for the solution under their supervision. In brief, qualities of software are the different
aspects used to measure the success of software systems. Qualities of software can be
divided into two categories 1) observable at runtime, and 2) not observable at runtime.

Observable qualities need to be an externally observable/measurable property of system

behavior, as opposed to its internal implementation. These observable qualities at runtime
provide value to the user and have more to do with short-term competitive differentiation.

For example, one quality observable at runtime is security, which is the measure of a
system's ability to resist unauthorized usage attempts and denial of service attacks while
still providing services to legitimate users.

Alternatively, qualities not observable at runtime influence the effort and cost associated
with the software development as well as support for future changes or uses. These

7
development-time qualities, for the most part, provide business value (as opposed to direct
value to the end user) and have to do with the long-term competitiveness of the business
charged with writing the software.4

Another quality, which is not observable at runtime, is testability. This quality is the ease
of ensuring software matches a system's functional and non-functional requirements.
Ironically, on any list of attributes that can be achieved via architectural means, testability
is not normally near the top of priorities.

There are other qualities of software that will be covered in greater detail in a forthcoming
part to this series. But the purpose here was just to mention that the responsibility of
ensuring qualities of software are met, lies primarily in the hands of the Solution Architect.

Software Development Process

The solution architect must define the software development process that accommodates
the specific needs of the business applications in development. While there are general
practices to software development at the enterprise level, there are often aspects of the
process which need more definition and refinement. The solution architect must help to
realize and specify this process into a format application developers can digest.

Incorporation of Software Frameworks

The purpose of a software framework is to provide an extensible template for software
applications. It is the solution architect's job to select and direct the use of an architectural
framework that supports the development community.

Software Tool Integration

Sometimes, this involves development tool customization, as it applies to that organization's
development process and culture. Therefore, the way one organization uses a development
tool will likely differ from the next. It will often take a seasoned veteran to recognize these
different needs to properly apply and make use of the tool investment.

Conclusion
The business of software architecture is to consistently deliver sound software architectures
that align the IT organization with business goals and processes of the organization—that is
the primary business challenge for the modern enterprise.

Interview business people in leadership about the role of the “architect” and you will likely
get a wide range answers. The reason for this is that modern organizations approach the
solutions to their problems in a vacuum of architectural leadership. The roles are not
defined well enough today in industry for there to be consistency in hiring the right
personnel for fulfilling the needs of software architecture in an organization.

To one organization, the enterprise architect might be someone experienced in enterprise

systems integration, to another, the role requirements involve more soft skills. Hopefully,
this article will help to provide organizational guidance to the organizational concerns for
software architecture.

Future parts to this series will define the what and how for consistently delivering sound
software architectures.

4
Lectures in Software Architecture By: Chandika Mendis

8
Appendix A – Architect Skills Matrix
This matrix represents the skill sets as they apply to the different architect roles described
in this paper. The columns correspond to the different architect roles. The rows in the
matrix are the skills.

Legend:

{ Awareness
Experienced
• Mastery

Business Enterprise Solution Application

Soft Skills
Communicates well with key { • { {

stakeholders
(C-level officers)
Communicates well with • • • {

stakeholders
(Director / Manager level)
Public Speaking • {

Writing Skills • • {

Hard Skills
Business Process Engineering • • {

Programming { { • •

Requirements Analysis • {

Software Design { • •

Quality Engineering { • {