The Perspective-Based Architecture Method

 

by Lewis Curtis and George Cerbone

Summary: The Perspective-Based Architecture (PBA) method is the result of over two years of field-based development. PBA has included contributions, case studies, and revisions from customers, international bodies, and field teams. The ultimate goal of the PBA method is to promote high-quality decision making, which is accomplished through three stages containing structured, focused questions. Step one is a series of questions capturing the perspective (what is your environment and where is it going?). Step two examines the impact of alternatives or existing proposals on the captured perspective (from step one). Step three examines the impact of the final proposal on the captured perspective (from step one). This simple structure works with all processes and methodologies, technologies, and documentation standards.

Contents

Today's Challenges
Introducing the PBA Method
The PBA Method Process
Does It Work?
Focusing Question Areas
About the Authors
Resources

Information technology has promoted a revolution in the modern world, enabling organizations to operate at faster, more productive levels. Automated collaboration software enables employees to work, communicate, and innovate anywhere, at any time, with anyone. Automated analysis engines can store and apply complex algorithms to large amounts of data from a variety of sources. Diverse organizations can communicate and integrate at speeds thought impossible ten years ago. Personal computers and mobile devices can enable ad hoc communities requiring almost zero administration.

With these innovations come increased competitive expectations. Markets that are used to innovating in the span of years are being challenged by newcomers that realize the power of innovating in weeks. This increased pressure has created the need for "extreme time to market" as businesses are forced by the marketplace to react more quickly to changes. Businesses are expecting employees to multitask to levels never before experienced in the workforce. Finally, as the Internet removes the friction associated with integration, companies are expected to integrate across geographic, lingual, political, and economic boundaries.

As organizational desires have grown and the technology sophistication has improved, IT architects are expected to make quick and cost-effective decisions for the organization. As the velocity of new solutions for the business increases, the complexity of aligning solutions with existing, current, and projected IT environments has created a quagmire drowning all who dare enter it. At the same time, business leaders are discovering IT architectural decisions are often some of the most important decisions impacting their organization, not just at the time that the decision is made, but also impacting subsequent decisions and plans.

In response to this enormous complexity, IT architects have developed terminology, techniques, methodologies, and processes to help them organize and manage complex architectural designs. Over the last 50 years these elements have significantly helped IT professionals decompose complex behavior and determine when and how to address specific issues and how to make and communicate decisions. Furthermore, a variety of quality checks and team modeling structures have been developed to encourage more precise and efficient activity.

For example, one mechanism that architects have developed for building reusable, decomposable structures is the design pattern. Design patterns are leveraged to build a predictable, reusable, and reliable solution. Many patterns are intended to give answers to common repeatable scenarios that we call answer patterns. The answer patterns have generally promoted a more consistent, predictable, and shorter time-to-market capability for many organizations.

Today's Challenges

However, while methodologies, processes, and answer patterns have significantly helped architectural efforts, many projects still fall far short of expectations even when using the best architectural compositions. Current models promote repeatable activity but not necessarily better decisions. They focus on the process of decision making, not the inputs or outputs. Existing methodologies and processes have addressed several questions:

  • When to make decisions?
  • Who makes a decision?
  • How to document decisions?
  • How to decompose parts of a decision?

Answer patterns have focused on: what are common responses for common scenarios?

Click here for larger image

Figure 1. An overview of the PBA method (Click on the picture for a larger image)

These are important questions, and existing methodologies have delivered good repeatable processes, communication methods, and answer patterns. However, we have not focused on the important questions architects should answer when engaging in any project. We have addressed the how, but not the what. Simply, if you don't ask the right questions, you will not look for the right answers. This situation is a critical weakness in IT architecture today. By focusing only on answer patterns and repeatable processes and methodologies, we have continually forced important projects to use designated answer patterns and methodologies that fit a particular frame of thinking. When these automated activities fail to fit with the current reality, architects operate in darkness, stumbling and experimenting to find the way to the light. The solution to this problem lies in changing the frame that defines our architectural thoughts.

The solution encompasses a new breed of architectural tools and structures that focus on addressing these critical questions:

  • What are good questions to ask when making good, discriminating architectural decisions?
  • How do I promote cohesive, well-thought-out decisions being considered on my project?
  • How do I avoid common pitfalls when making architecture decisions?

Successful senior IT architects often possess three fundamental capabilities when making decisions: knowledge, experience, and perspective.

Knowledge is the first area of development for any new IT architect. IT architects must possess a good fund of general knowledge spanning many disciplines. They must study and analyze vigorously to keep their knowledgebase as current and timely as possible.

Bb245776.jour9method02(en-us,MSDN.10).gif

Figure 2. The PBA method's question structure meta model

Experience represents the second stage of an architect's career. Knowledge by itself does not an architect make. Architects attain experience observing best practices and pitfalls. Experience can be obtained from firsthand activity or reusable, knowledge-based communication from the experiences of others. Reusable experiences have been the catalyst to promote repeatable solutions, design patterns, and consistent architectural operations, which is the core source of answer patterns. Answer patterns are an attempt to codify and transfer experience, without the "pain" of firsthand discovery. Organizations have promoted best practices as a technique to capture answer patterns and processes of successful architects. While this technique has been very positive for the community, the answer pattern structure and process can also promote confusion when professionals fail to find patterns working for their specific engagement.

Bb245776.jour9method03(en-us,MSDN.10).gif

Figure 3. The four core zones

However, experience alone often isn't enough to promote quality decision making and analysis. Inspired by the book Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell, and one of the books Gladwell's book was based on, Simple Heuristics that Make Us Smart, we found highly successful architects were able to make excellent analysis and architectural decisions in a short amount of time. When examining these architects, we found they often had equivalent levels of experience and knowledge as teams of architects working on the problem for a much longer time.

Bb245776.jour9method04(en-us,MSDN.10).gif

Figure 4. The requirements environment

So what was the difference? How are some architects able to produce higher levels of analysis and architectural proposals with the same level of experience and knowledge? The answer was their perspective. They often started with quality questions and viewed architectural decisions from an ecosystem impact view rather than a technical capability view. Because they often emphasized examining the impact of decisions on an organization, they had refined their intuitive capability to see impact patterns within a short amount of time. It was this finding that inspired the study and development of a method that promoted this capability in our architects.

Bb245776.jour9method05(en-us,MSDN.10).gif

Figure 5. The business environment

Simply, perspective represents the frame of understanding an architect brings to an engagement. Perspective represents an architect's ability to understand the impact of his or her discriminating decisions on the environment. This skill is the most challenging that an architect must attain. Most peer-respected IT architects demonstrate significant perspective-based skills. They operate with a more comprehensive frame of understanding. Developing and organizing that frame of understanding is the purpose of the PBA method (see Figure 1).

Introducing the PBA Method

Technology leaders making discriminating, mission-critical decisions for their organizations understand the importance of a mature perspective. Those who can see the larger picture and ask quality questions often develop quality solutions for their organizations.

Bb245776.jour9method06(en-us,MSDN.10).gif

Figure 6. The IT environment

When Lewis's grandfather led teams setting up satellite information communication systems in Turkey and other precarious areas during the Korean and Cold Wars, he faced monitoring and management issues, significant security issues, scalability issues, operational process issues, time pressures, and critical organization activities that were dependent on the reliability of the systems. Lives depended on these systems' operation. The issues faced in this system are nothing new, but the lessons learned are often forgotten, which is not unusual. In interviewing professionals outside the field of information technology, we found perspective is the most challenging and most desired attribute for a seasoned professional.

Therefore, the Perspective-Based Architecture (PBA) method is designed to be very simple. It does not care when you make a decision, what your title is, how you document decisions, or what taxonomy you use when examining an architecture. It can complement any structure needed. Simply, the purpose was not to reinvent existing professional structures but rather to complement current models, methods, and processes to drive more successful projects (see Figure 2).

Bb245776.jour9method07(en-us,MSDN.10).gif

Figure 7. The trends, forecasting environment

To organize the questions, the PBA method divides the perspective into four broad zones: requirements; business environment; IT environment; and trends, forecasting (see Figure 3). Seasoned professionals will notice the importance of forecasting and time, two areas often overlooked in decision making. These zones by themselves are too broad for question-structure organization. Therefore, each broad zone contains many more focused areas of concern. This decomposition enables the architect to differentiate focused areas more easily. Each focused area of concern contains a number of questions for perspective capture, examining the impact from alternative proposals and examining the impact of the final proposal.

While this method might appear complicated for some, it's actually quite simple. Common questions were grouped together by subject to allow greater clarity and organizational understanding. (See the sidebar, "Focusing Question Areas" for question area examples organized by zone.)

The requirements zone represents common core questions and areas of concern for the specific project being considered (see Figure 4). Historically, this zone is where most architects have focused their time and energy on these areas of concern:

  • Current utilized solution(s)
  • Functional requirements
  • Systemic quality (nonfunctional) requirements
  • Project constraints (time, resources, and money)
  • Stakeholders for the solution
  • Executive sponsor(s)
  • Business metric requirements related to the solution
  • Communication requirements for the solution and project team

The business environment zone represents critical questions for the business. These sections focus on relevant parts for the operationally successful organization in the market (see Figure 5). This section does not consider the IT environment; rather, it is entirely business focused. The business environment must be addressed in the language, taxonomy, and structure the business really uses for this analysis to be successful. Focused areas of concern are:

  • Corporate strategic goals
  • Customer market
  • Political environment
  • Organizational dynamics
  • Industry business regulations/laws
  • Business process standards
  • Business unit(s) metric standards
  • Corporate business policy standards
  • Business unit(s) objectives
  • Competitive landscape

The IT environment zone represents the operational IT structures, processes, issues, and systems for all important technology activity for the organization (see Figure 6). Similar to the business environment, IT questions must be addressed using the language of IT. Focused areas of concern are:

  • IT recoverability systems
  • IT operational time pressures
  • IT operational processes
  • IT operational resource pressures
  • IT operational financial pressures
  • IT physical facility capabilities
  • IT data center services
  • IT development/test environment
  • IT operational technical pressures
  • IT operational metrics
  • Corporate IT standards
  • IT provisioning, patch, and deployment systems
  • Instrumentation, monitoring, and troubleshooting IT systems
  • IT security environment
  • IT operational risk tolerance level(s)
  • Other systems in the IT environment (existing and planned)

The trends, forecasting zone considers the time dimension and represents future directions for the IT environment, business environment, forecasted technologies/solutions, and architectural patterns relevant to the current solution being considered by the architecture team (see Figure 7). Architects must be able to honestly and effectively forecast and analyze trends properly. Focused areas of concern are:

  • Current corporate IT operational trends
  • Market IT operational trends
  • General market business trends
  • Applicable industry trends
  • Specific corporate trends
  • Specific business unit(s) trends
  • Solution architecture trends
  • Infrastructure architecture trends
  • Architectural design trends
  • Technology trends

The PBA Method Process

The PBA method is designed to be simple and align with most processes being used today. The process involves capturing the perspective and then using that capture to understand the impact of various architectural decisions (see Figure 8). Using the PBA method proactively with your favorite design methodology or process helps promote better decision making during the architectural design experience rather than in hindsight. Let us take a look at the process.

Step one: Capture the perspective. Each subarea has detailed questions asking the architectural team to describe what they understand specifically. An interesting feature of the PBA method is that "I don't know" is an acceptable answer. For areas where they do not have answers, they write, "I (or we) do not know the answer." This feature enables the entire team to transparently understand the perspective more comprehensively, while being honest about areas of uncertainty, and promotes cross-team collaboration and open communications for critical engagements. With a unified collaborative perspective capture, the team can begin examining the impact of multiple proposals more effectively.

Step two: Examine the impact of alternative proposals. This step involves a series of structured impact questions for each subarea in the perspective capture and focuses on alternative or existing proposals (depending on the situation) and their impact on the captured perspective. Again, architects must document both what impact they understand and what impact areas they are uncertain of.

Bb245776.jour9method08(en-us,MSDN.10).gif

Figure 8. Process structure for the PBA method

Step three: Examine the impact of the final proposal. This step involves a similar (to step two) series of structured impact questions, except this step focuses on the final proposal. By using the same perspective capture (as in step one), the impact analysis promotes a more balanced and open approach and drives decisions encouraging best-fit models for the specific organization or business. While answering the question areas, architects can use any tools, methodologies, or architectural processes needed for the project. Often, an architect will use the information for comparison analysis and communicating decision justifications. Something we found more interesting was that the structure promoted higher-quality decisions aligning with the business, organizational structures, and trends rather than merely promoting a favorite technology, product, or technique. In other words, because architects had to address the perspective from a more comprehensive viewpoint, their decisions aligned much more effectively.

A common question for the process is: "Do step two and step three need to be sequential?" Not at all. Architects can reverse the order of step two and three or even conduct them in parallel, depending on specific needs. The most important point is doing step one first!

We found as organizations moved into their second project using PBA, many perspective-based questions where already answered, or they changed very little. The new project team operates with more impact awareness moving toward decisions and analysis at a faster pace. Architectural teams become incrementally more effective through this continuous learning model.

Does It Work?

Working with Federated Systems Group under the direction of Brian Derda, we conducted an unbiased case-study program. It was controlled by Federated Systems Group with architects from three different companies working under very short deadlines. Using a Groove collaboration workspace populated with material from the PBA method, the team rapidly assembled high-quality strategic and tactical analysis with better recommendations and decisions as evaluated by both Federated Systems Group and Microsoft.

Bb245776.jour9method09(en-us,MSDN.10).gif

Figure 9. Sample functional requirements area questions

Furthermore, we found the PBA method promoted dialogue between diverse organizations and companies, reduced confusion between team members, and promoted a higher level of trust with transparent analysis exposure. Finally, we discovered the PBA method was very easy to learn, and teams began engaging with this framework within a very short time frame (see Resources).

Successful and respected architects already implicitly use many of these questions today in their architectural analysis to make good decisions. The PBA method focuses on enabling architects to operate more efficiently with a perspective-based framework. This efficiency is accomplished through a reusable question model with well-defined subject areas encapsulated in a simple and easy-to-learn structure. Of course, making difficult decisions often means answering challenging questions, and while the structure is simple, the questions can be quite challenging.

Furthermore, the PBA method represents a living architecture method. It grows, adapts, and evolves from field, international body, customer, and partner participation. This approach is very different from past architecture methodologies and processes.

Finally, it can work side-by-side with anything. The power of the PBA method is its simplicity and focus. We invite you to become involved in leveraging and evolving the PBA method (see Resources).

Focusing Question Areas

Organizations are expanding the scope of IT architectural responsibility to more individuals. Here are some sample questions that are formulated correctly and organized for applying the PBA method specifically to address specific endeavors proactively.

Requirements Zone: Functional Requirements

Attaining good functional requirements is often fundamental toward arriving at any good solution. Working with customers and field teams for the last two years, we found there are several fundamental questions that must be answered no matter what methodology, process, or technology is used and no matter for which vendor (see Figure 9). We found also that by interviewing retired IT professionals working on past projects, management assumed they could always answer these fundamental questions. Of course, the quality and depth of answers coming from IT architectural professionals varies widely.

  1. Who will interact with this solution (people, systems, and so on)?
  2. How will these people and/or systems interact with this solution?
  3. What do these people and/or systems expect functionally and to be observable from the solution?
  4. Why do they want or need this specific functionally observable behavior delivered?
  5. How will these functional expectations evolve over time?
  6. What is the expected functional lifespan of this solution?

Business Environment Zone: Political Environment

Political power is the influence and control by individuals or groups to direct money, resources, time, strategy, and tactics of an organization toward its desired goals. Understanding and capitalizing on a political environment through executive sponsors and stakeholders using direct and indirect ethical influencing capabilities represents important skills of a seasoned corporate IT architect.

The political ecosystem represents a significant factor in the success of any ongoing IT initiative. It is critical that architects carefully understand the political dynamics and make decisions cohesive with that particular political landscape. Architecture decisions influence and are influenced by political forces within any organization. Here are some common questions that should be addressed by the architecture team, organized by section:

Perspective Capture

  1. Who are the significant political influencers in the organization?
  2. Which political influencers could impact this solution?
  3. What are the motivators of these political influencers?
  4. Are there any political landscape issues that should be known?

Current or Alternative Impact

  1. How do (or could) technology decisions of the current or alternative architecture design affect the political landscape?
  2. How does (or could) the current or alternative architectural development plan impact the political landscape?
  3. How do (or could) the current or alternative architectural deployment and transition plans affect the political landscape?
  4. How does (or could) the process and role ownership model for the current or alternative architectural decisions affect the political landscape?
  5. How will (or could) the executive sponsor(s) be affected by this potentially altered political landscape from the current or alternative architecture decisions?

Proposed Impact

  1. How does (or could) the proposed architectural development plan impact the political landscape?
  2. How do (or could) the proposed architectural deployment and transition plans affect the political landscape?
  3. How does (or could) the process and role ownership model for the proposed architectural decisions affect the political landscape?
  4. How will (or could) the executive sponsor(s) be affected by this potentially altered political landscape from the proposed architecture decisions?
  5. How do (or could) technology decisions of the proposed architecture design affect the political landscape?

IT Environment Zone: IT Management Systems

Most enterprise organizations have systems, processes, techniques, staff, and so on to troubleshoot, conduct some sort of root-cause analysis, and repair a solution's system component when needed. The need to reduce mean time to repair (MTTR) is crucial for a company to handle normal and abnormal exceptions in their day-to-day activities. The solution must align itself well with the current and forecasted troubleshooting and repair environment that organizations use to keep their IT operations successful:

Perspective Capture

  1. What systems and processes exist for troubleshooting and root-cause analysis in the IT organization?
  2. How are these systems and/or processes for troubleshooting and root-cause analysis used in the IT organization?
  3. What solutions are managed by these systems and processes for troubleshooting and root-cause analysis?

Requirements Zone: Current Solution(s)

As IT reuse is vital for organizations, leveraging existing capabilities is important as long as they align with the business's tactical and/or strategic goals. It is always important to understand what is currently providing any of the functional and/or nonfunctional needs of the initiative:

Perspective Capture

  1. What systems currently provide any of the scoped functional needs for the recognized stakeholders?
  2. What is the architectural design of these systems?
  3. When were these solutions designed and deployed?
  4. Who designed and deployed these solutions?
  5. Why were these solutions originally designed and deployed?
  6. What is the general impact of these systems on the organization?

Trends, Forecasting Zone: Industry Vertical Directions/Trend(s)

While the general market directly impacts industry trends, these trends dramatically impact the organization and the success of most IT solutions. In other words, understanding industry trends is crucial toward increasing the business viability of the solution being designed:

Perspective Capture

  1. What are the relevant industry vertical directions/trends?
  2. Why are these vertical industry directions/trends significant for the business?
  3. How is the business addressing these vertical industry directions/trends?

About the Authors

Lewis Curtis is an infrastructure architect evangelist for developer and platform evangelism, east region, Microsoft Corporation. He is a Microsoft Certified Architect in infrastructure and a member of the MCA board of directors. Contact Lewis at lewis.curtis@microsoft.com or here.

George Cerbone is an infrastructure architect evangelist for developer and platform evangelism, financial services, Microsoft Corporation, and a Microsoft Certified Architect in infrastructure. Contact George at george.cerbone@microsoft.com or at his blog.

Resources

Gladwell, Malcolm. Blink: The Power of Thinking Without Thinking. New York, NY: Little, Brown and Company, 2005.

Perspective-Based Architecture
The PBA Method

Gigerenzer, Gerd, Peter M. Todd, and the ABC Research Group (general editor: Stephen Stich). Simple Heuristics that Make Us Smart. New York, NY: Oxford University Press, 2000.

Skyscrapr
ARCast: Perspective-Based Architecture

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.

Show: