Architecture is the bridge between (often abstract) business goals and the final (concrete) resulting system.
A software architect should act as a bridge between business stakeholders and technical stakeholders. To be this bridge requires understanding the business problem being solved, and being able to distill that problem into a technical solution that a software team can implement. In essence, the architect acts as a technical business analyst that helps to define the needs of an organization and recommend solutions that deliver value to stakeholders. It just so happens that an architect’s stakeholders include project managers, software developers, management, and other software architects. This article describes how a software architect can apply methods from business analysis to make their job easier and to satisfy these different stakeholders.
Key Responsibilities
The key responsibilities of a business analyst are the discovery of underlying business needs, specifying and organizing requirements, and validating that requirements are being met. Depending on the role, a professional business analyst may be involved in project management, and in business planning. In most organizations, these responsibilities are similar to those of a software architect, and the software architect can apply business analysis techniques to help move projects forward, while keeping all stakeholders informed in language they feel most comfortable with.
The Business Analysis Process
Business analysis is primarily a research discipline of identifying business needs and determining solutions to business problems. As a research discipline, several techniques have been developed to aid a business analyst in doing their job. By following these techniques as an architect, you can take advantage of a clear method for engaging and communicating with business stakeholders, and clearly communicate the value you are providing to the organization by taking on this role.
One such technique is the 8-step business analysis process. Here, I will walk through that process with a particular emphasis on the issues faced by a technical software architect.
Step 1 - Get Oriented
When starting a new project — or helping to define the architecture for an existing one — a strong tendency is to start making positive change as soon as possible. This is often coupled with the feeling that we need to “prove ourselves” to stakeholders. By acting too quickly, we act without a full understanding of the business problem, and without a full understanding of existing assumptions. This can easily lead to false starts in the wrong direction.
Instead, by taking some time to get oriented with the project and with any stakeholders you will ensure you are able to be an effective and confident contributor on the project.
At this step in the analysis process, your responsibilities as architect should include:
- Determining the primary stakeholders to engage in defining the project’s architectural requirements and scope
- Clarifying your role as the architect, and making sure other stakeholders understand that role.
- Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
- Understanding the existing systems and business processes so you have a reasonably clear picture of the current state.
Step 2 - Discover the Business Goal
An architecture is not valuable unless it solves a business problem. As an architect, it is your job to help define the business objectives in conjunction with project managers and business analysts. It is tempting to have managers and analysts simply hand business requirements to an architect, and then try and implement them. Unfortunately, communication is not usually so simple. Instead, it is your job to help the business understand how architecture affects a project’s requirements and scope.
Your key responsibilities in this step include:
- Discover why this project exists. What is the business goal?
- Reconciling conflicting expectations so that the business community begins the project with a shared understanding.
- Ensuring the business objectives are clear and actionable.
Step 3 - Limit Scope
A project’s architecture has clear implications on a project’s timeline and scope. By providing a clear and complete statement of scope, you allow the development team the ability to move forward, and you provide a common set of expectations for business stakeholders.
Your key responsibilities in this step include:
- Clarifying scope with both business and technology stakeholders.
- Confirming the business case to ensure that it still makes sense for your organization to invest in the project.
Step 4 - Formulate a Plan
At this point, you can start to formulate an architectural plan that satisfies the scope of the project. This plan will help you to clarify the project itself and help with detailing any necessary requirements.
Your key responsibilities in this step include:
- Determine a rough architectural plan.
- Choosing the most appropriate types of deliverables for your work: diagrams, text, presentations, etc.
- Identify any project timelines for completing the work.
Step 5 - Detail any Requirements
Any detailed requirements should help the technology team implement the solution. They turn an abstract scope into an implementable solution.
Your key responsibilities in this step include:
- Helping business stakeholders define their explicit requirements.
- Analyzing requirements to make sure they are technically sound and implementable.
- Reviewing and validating each requirement with the technology team and asking questions to fill in any gaps.
Step 6 - Support the Technical Implementation
As an architect, you are also technically capable of helping with the implementation. This help may take the form of coding, prototyping, or doing code review. It may also take the form of a sounding board for the team to bounce ideas off of. Your support role may also change depending on the qualities of the team you are working with. Some teams may need more hands-on technical support, while other teams are able to act independently and need more guidance when interacting with business stakeholders.
Your key responsibilities in this step include:
- Reviewing the design to make sure it meets the business and architectural goals.
- Updating and/or repackaging any documentation to make it useful for the technology design and implementation process.
- Engaging with any test teams to make sure they are able to test the project against the requirements.
- Making yourself available to answer questions and help resolve any issues that surface during the technical design, technical implementation, or testing phases of the project.
Step 7 - Support the Business Implementation
In some cases, the architect is responsible for helping implement the solution. This may require coding certain aspects of the application, but it also means updating any business documentation or user documentation for people using the solution. At this point, you may need to engage stakeholders and explain the new solution to them, taking their feedback back to the team.
Your key responsibilities in this step may include:
- Talking with end users to ensure they understand the new system, including any limits or restrictions.
- Collaborating with business users to understand any business impact of adopting the new technical solution.
Step 8 - Evaluate the Solution
During development of a new project, it is easy to lose sight of the original purpose. Although this step is listed last, validating that the solution meets the requirements of the business should be happening at all times throughout the development of the project. Nearing the end of the project, I usually work more closely with any QA stakeholders to help define the testing and validation requirements and make sure that they meet the needs of the project.
Your key responsibilities in this step may include:
- Evaluating the actual project against the business objectives for the project.
- Communicating the results of the project to the business.
- Suggesting follow-up projects and initiatives to fully realize the intended business objectives of the project or to solve new problems.