After two years of field development with contributions, case studies from customers, international bodies and field teams, The PBA Method has matured into a viable structure promoting quality decisions with simplicity and ability to work with any process or methodology.
The PBA Method is a simple structure to promote higher quality decision making. This 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. After two years of research and work with international bodies, customers and field teams, The PBA Method was developed to fill a missing element for the architecture community; drive better decisions by capturing better questions. Finally, The PBA Method represents a living architectural methodology. Questions and perspective structure can evolve over time that transcends current common patterns, methodologies, processes, technologies and operational structures. Customers, partners and international bodies have communicated a interest to participate in growing, promoting and capitalizing on The PBA Method.
Current State of Affairs
Technology has truly become an amazing enabler for organizations to operate at faster more productive levels. Automated collaboration software enables employees to work, communicate and innovate anywhere at any time with anyone needed. Automated analysis engines can store and apply complex algorithms to larger 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 create ad-hoc communities with almost zero administration. Information technology has promoted a revolution in the modern organization.
With these innovations come increased competitive expectations. Markets innovating in years are realizing the power of innovating in weeks. This is what I call extreme time to market pressure. Furthermore, with enablement comes creative business integration expectations crossing geographic, lingual, political and economic boundaries. Finally, businesses are expecting employees to multi-task to levels never before experienced in the workforce. Our world is changing rapidly.
As organizational desires have grown and the technology sophistication has improved, IT architects are expected to quickly and cost effectively make successful decisions for the organization. Business leaders are discovering IT architectural decisions are often some of the most important decisions impacting their organization.
Furthermore, as the velocity of new solutions for the business grows, the complexity of aligning solutions with existing, current and projected IT environments has often transformed itself into a quagmire drowning all who dare enter it.
To handle the increasing velocity of expectations and the growing quagmire, IT architects have been developing terminology, techniques, methodologies and processes to help them organize and manage complex architectural designs. Over the last fifty years, these have significantly helped IT professionals decompose complex behavior, determine when and who addresse specific issues and how decisions are decomposed and communicated effectively. Furthermore, a variety of quality checks and team modeling structures have been developed to encourage more precise and efficient engagement activity.
In addition, design patterns have become important for reusable decomposable structures enabling architectures to demonstrate a more predictable, reusable and reliable solution. This is what I call answer patterns. Answer patterns give short focused answers to common repeatable scenarios. While marketing professionals from reputable vendors have latched on this idea with vigor (at times, creating some confusion), the use of answer patterns have generally promoted a more consistent, predictable and faster time to market capability for today’s extreme time to market culture.
Why this is not working
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. The reason: current models promote repeatable activity but not necessarily better decisions.
Methodologies and Processes have promoted
- When do I make a decision?
- Who makes a decision?
- How do I document a decision?
- How do I decompose parts of a decision?
Answer patterns have focused on:
- What are common responses for common scenarios?
However, while we have focused on good repeatable processes, communication methods and answer patterns, we have not focused on the important questions architects should answer when engaging in any project. Simply, if you don’t ask the right questions, you will not look for the right answers. This is our critical weakness in the field of 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 which fit our frame of thinking. When these automated activities fail to fit with current reality, we operate in architectural darkness stumbling and experimenting to find our way to the light. What we really need to accomplish is changing the frame which defines our architectural thoughts.
What is needed
We need a new breed of architectural tools and structures which focus on addressing 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?
Why is this new model needed?
In the last two years, I found senior IT architects often possess three fundamental capabilities for success when making decisions.
Knowledge
Architects must understand vast amounts of technical and non-technical information. IT Architects often study and analyze vigorously to keep their knowledgebase as current and timely as possible. This is the first area of development for any new IT architect.
Experience
Architects attain experience observing best practices and pitfalls. Experience can be obtained from first hand 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. Since experiences vary significantly, organizations have promoted “best practices” as a technique to capture answer patterns and processes of more successful architects in the past. While this 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. Experience represents the 2nd stage of an architect’s career.
Perspective
Perspective represents an architect’s ability to understand the impact of his or her discriminating decisions on the environment. From the last two years of field research, working with important customers and observing senior candidates for several MCA boards, perspective represents the most challenging skill an architect to attain in their development. Simply, perspective represents the frame of understanding an architect brings to an engagement. From my analysis, most peer respected IT architects demonstrate significant perspective based skills in their engagement activity. They operate with a more comprehensive frame of understanding. Developing and organizing that frame of understanding represents the purpose of The PBA Method.
The PBA Method
For fifty years, technology leaders making discriminating mission critical decisions for their organization have understood the importance of a mature perspective. Those who can see the larger picture and ask quality questions often developed quality solutions for their organizations.
When my grandfather initially lead mission critical teams setting up satellite information communication systems in Turkey and other precarious areas during the Koren and Cold War, he had monitoring and management issues, security issues (significant security issues), scalability issues, operational process issues, time pressures and critical organization activities dependent on the reliability of the systems (many times, lives were dependent on its operation). Many questions I ask myself today in an engagement are nothing new but often forgotten.
This is not unusual. In interviewing professionals outside the field of information technology, I found perspective as being the most challenging and most desired attribute for a seasoned professional.
Therefore, The PBA Method is designed to be very simple. It doesn’t 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 compliment any structure needed. Simply, the purpose wasn’t to re-invent existing professional structures but compliment current models, methods and processes to drive more successful projects.
Basic Structure of The PBA Method:
To organize the questions, The PBA Method divides the perspective into 4 broad zones; Requirements Zone, Business Environment Zone, IT Environment Zone and Trends-Forecasting Zone (notice the importance of forecasting and time). 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 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 might appear complicated for some, it’s really simple. Common questions were grouped together by subject to allow greater clarity and organizational understanding.
The question structure meta-model of The PBA Method
The Four Broad Core Zones:
Requirements Zone
This zone represents common core questions and areas of concern for the specific project being architecturally considered. Historically, this is where most architects have focused their time and energy.
Focused Areas of Concern
- Currently utilized solution(s)
- Non-functional (systemic quality) requirements
- Functional requirements
- Project constraints (Time, Resources, Money)
- Executive Sponsor(s)
- Stakeholders for the solution
- Business Metric Requirements related to the solution
- Communication Requirements for the solution and project team
Business Environment
This zone represents critical sections of the business. These sections focus on relevant parts for the operationally successful organization in the market. Furthermore, there is no IT translation activity in this area. Translation: The business environment must be addressed in the language, taxonomy and structure the business really utilizes.
Focused Areas of Concern
- Corporate Strategic Goals
- Political Environment
- Organizational Dynamics
- Financial Environment
- Industry Regulations/Laws
- Business Process Standards
- Corporate Policy Standards
- Business Unit(s) Objectives
- Customer Market
- Competitive landscape
IT Environment
The IT environment represents the operational IT structures, processes, issues and systems for all important technology activity for the organization.
Focused Areas of Concern
- Recoverability Systems
- Time Pressures
- Operational Pressures
- Resource Pressures
- Financial Pressures
- Physical Facility Capabilities
- Data Center IT Services
- Development /Test Environment
- Technical Pressures
- Instrumentation, Monitoring and troubleshooting systems
- IT Security Environment
- Operational Metrics
- Provisioning, Patch and Deployment Systems
- Corporate IT standards
- Other external systems (existing and planned)
- Risk Tolerance Level(s)
- Enterprise Architectural Environment
Trends / Forecasting Projections
This zone represents future directions for the IT environment, Business environment and forecasted technologies/solutions and architectural patterns relevant to the current solution being considered by the architecture team. Architects must be able to honestly and effectively forecast and analyze trends properly.
Focused Areas of Concern
- Current Corporate IT Environment Trends
- IT Environment Trends in the Market
- General Market Business Trends
- Applicable Industry Trends
- Specific Corporate Trends
- Specific Business Unit(s) Trends
- Solution Trends
- Architectural Design Trends
- Technology Trends
The Process of The PBA Method
The process of The PBA Method is not extraordinary. It’s simple and often, it aligns with most processes being utilized today. The process involves capturing the perspective and then using that capture to understand the impact of various architectural decisions. Using it 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.
Step One: Capture the Perspective
Each sub area has detailed questions asking the architectural team to describe what they specifically understand. For areas where they do not have answers, they write “I (or we) do not know the answer.” This enables the entire team to transparently understand the perspective more comprehensively while being honest about areas of uncertainty. This 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: Examining the Impact of Alternative proposals
Step two involves a series of structured impact questions for each sub area of concern in the perspective capture. The step focuses on alternative proposals (or existing depending on the situation) and its impact to the captured perspective. Again, architects must document what impact they understand and what impact areas they are uncertain of.
Step Three: Examining the Impact of the final proposal
Step three involves a similar series of structured impact questions step two focusing on the final proposal. By utilizing the same perspective capture (step one), the impact analysis promotes a more balanced and open approach and drive decisions encouraging best fit models for the specific organization or business.
While answering the question areas, architects can utilize any tools, methodologies, architectural processes needed for the project. Often, an architect will utilize the information for comparison analysis and communication of decision justification activity. Something we found more interesting: the structure promoted higher quality decisions aligning with the business, organizational structures and trends rather than merely promoting a favorite technology, product or technique. Because architects had to address the perspective from a more comprehensive viewpoint , their decisions aligned much more effectively.
Common Question for the Process:
Question: “Does Step two and three need to be sequential?”
Answer: Not at all. Architects can reverse step two and three or even conduct them in parallel depending on specific needs. The most important point is doing step one first!
Does it work?
Working with a customer: 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 3 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 recommendations quickly and with better decisions as evaluated from Federated Systems Group and The research team.
Furthermore, we found The PBA Method promoted more dialogue between diverse organizations and companies, reduced confusion between team members and promoted a higher level of trust with transparent exposure of analysis. Finally, we discovered The PBA Method was very easy to learn and teams began engaging with this framework within very short time frame.
Conclusion:
Successful and respected architects already use many of these questions today implicitly 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 is accomplished through a reusable question model with well defined subject areas encapsulated in a simple and easy to learn, structure. Of course, while the structure is simple, the questions can be quite challenging. Of course, making good difficult decisions often means answering challenging questions.
Furthermore, The PBA Method represents a living architecture method. It grows, adapts and evolves from field, international bodies, customer and partner participation. This is a very different approach 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. I invite you to become involved in leveraging and evolving The PBA Method. For more information on The PBA Method, go to:
www.perspectivebasedarchitecture.com (awaiting approval to populate for the general public)
thank you,
Lewis Curtis
Appendix: Question Examples:
Requirements Zone: Functional Requirements Area
Attaining good functional requirements are often fundamental towards attaining any good solution. Working with customers and field teams for the last two years, we currently found 6 fundamental questions which must be answered no matter what methodology, process, technology or vendor is currently utilized. (listed below). Furthermore, we found that by interviewing retired IT professionals working on past projects, management assumed they could always answer these 6 fundamental questions. Of course, the quality and depth of answers coming from IT architectural professionals varies widely (utilized advanced decomposition and diagramming techniques with the latest taxonomies to associated functional qualities properly). With companies expanding the scope of IT architectural responsibility to more and more individuals, it is of little surprise to find those troubled searching for the correct questions to proactively address in their endeavors.
Business Environment Zone: Political Environment Area:
Political power is the influence and control capability by an individual or group to direct money, resources, time, strategy and tactics of an organization towards their desired goals. Understanding and capitalizing on a political environment through executive sponsors and stakeholders through 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 is influenced by political forces within any organization. Here are some common questions which should be addressed by the architecture team.
FROM THE PERSPECTIVE CAPTURE SECTION
- Who are the significant political influencers in the organization?
- Which political influencers could impact this solution?
- What are the motivators of these political influencers?
- Is there any political landscape issues that should be known?
FROM THE CURRENT OR ALTERNATIVE IMPACT SECTION
- How do (or could) technology decisions of the current or alternative architecture design affect the political landscape?
- How does (or could) the current or alternative architectural development plan impact the political landscape?
- How do (or could) the current or alternative architectural deployment and transition plans affect the political landscape?
- How does (or could) the process and role ownership model for the current or alternative architectural decisions affect the political landscape?
- How will (or could) the executive sponsor(s) be affected by this potentially altered political landscape from the current or alternative architecture decisions?
FROM THE PROPOSED IMPACT SECTION
- How does (or could) the proposed architectural development plan impact the political landscape?
- How do (or could) the proposed architectural deployment and transition plans affect the political landscape?
- How does (or could) the process and role ownership model for the proposed architectural decisions affect the political landscape?
- How will (or could) the executive sponsor(s) be affected by this potentially altered political landscape from the proposed architecture decisions?
- How do (or could) technology decisions of the proposed architecture design affect the political landscape?
IT Environment Zone: IT Management Systems Area
Most enterprise organizations have systems, processes, techniques, staff, etc… to troubleshoot, conduct some sort of root cause analysis and repair a solution’s system component when needed. The need to reduce MTTR (mean time to repair) 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 organizations utilize to keep their IT operations successful.
FROM THE PERSPECTIVE CAPTURE SECTION
- What systems and processes exist for troubleshooting and root cause analysis in the IT organization?
- How are these troubleshooting and root cause analysis systems and/or processes utilized in the IT organization?
- What solutions are managed by these troubleshooting and root cause analysis systems and processes?
FROM THE CURRENT OR ALTERNATIVE IMPACT SECTION
- What was (or could be) the impact of current or alternative architecture decisions on the existing troubleshooting and root cause analysis systems in the IT organization?
FROM THE PROPOSED IMPACT SECTION
- What could be the impact of the proposed architecture decisions on the existing troubleshooting and root cause analysis systems in the IT organization?
Requirements Zone: Currently Utilized Solution(s) Area:
As IT Reuse is vital for organizations, leveraging existing capability is important as long it aligns with the business’s tactical and/or strategic goals. It is very always important to understand what is currently utilized to provide any of the functional and/or non-functional needs of the initiative.
FROM THE PERSPECTIVE CAPTURE SECTION
1) What currently utilized systems provides 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?
FROM THE CURRENT OR ALTERNATIVE IMPACT SECTION
7) Can any existing technical designs be leveraged at the appropriate supportable scope and scale for the alternative/existing proposals?
FROM THE PROPOSAL IMPACT SECTION
7) Can any existing technical designs be leveraged at the appropriate supportable scope and scale for the final proposed solution?
Trends-Forecasting Zone: Industry Vertical Directions/Trends Area:
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 towards increasing the business viability of the solution being designed.
FROM THE PERSPECTIVE CAPTURE SECTION
- What are the relevant industry vertical directions/trends?
- Why are these vertical industry directions/trends significant for the business?
- How is the business addressing these vertical industry directions/trends?
FROM THE CURRENT OR ALTERNATIVE IMPACT SECTION
- How do current or alternative architecture decisions align with current industry vertical directions/trends?
FROM THE PROPOSED IMPACT SECTION
- How do proposed architecture decisions align with current industry vertical directions/trends?
