Chapter 14 - Solution Architect's Perspective

The solution architect is typically part of the product development team . Their role in the acceptance process usually involves approving design and technology decisions, designing data models and domain models, and ensuring that the product as built satisfies the needs of the end users. The role transcends different parts of the product development team’s organization as the solution architect is responsible for the whole solution whereas individual component teams or feature teams are each only responsible for a part.

Responsibilities Overview

As a solution architect, your job is to ensure the entire solution satisfies the product owner and the potential users of the system. You responsibilities include: Your role in the acceptance process will primarily focus on the readiness assessment activities but you should also be involved in helping the product owner understand what they want the product owner team to build and facilitate the communication of that information to the product owner team. Your involvement in acceptance testing may be minimal but you may be called upon to interact with acceptance testers which may include enterprise architects assessing compliance to architectural guidelines and standards.

Understanding the Solution

You need to work with the product owner to understand their vision of the product and to help them understand what options are available to them with respect to building that product. Less technical product owners may need your help to define the product based on more general needs. You will likely want to engage user experience experts if good usability is a requirement. You will also need to help the product owner understand the relative costs of various options presented to them so they can make the right tradeoffs based on return on investment. This may require unbundling of some functionality into smaller, more atomic, features that can be prioritized separately.
Be aware that the product owner may not be aware of all the requirements for the product; it may be up to you to help them engage the operations manager, security architects, and other stakeholders so that all the requirements for the product become known. Discovering security requirements or mandatory service level agreements late in a product development cycle is sure to result in a late product.
For larger products you may be called up to help make the project manager or product owner decide whether to divide the product owner team into feature teams or component teams and to subdivide the feature backlog into feature team backlogs or decompose the feature backlog into component backlogs. Where a mix of technologies is involved (including mixed hardware/software products), you must be prepared to be involved in negotiating the interfaces between the various technologies.
Regardless of the size of the product owner team, it is important for everyone to understand the overall solution and how their part fits into it. This can help avoid situations where each component works according to specification but when integrated fail to provide the seamless experience the product owner would expect.

Ensuring Readiness

As solution architect, the onus is on you to do everything you can to ensure that the product is ready before the readiness decision needs to be made. Things will go a lot smoother if everyone on the team understands what done looks like. This is especially true for component teams whose work needs to be integrated before acceptance testing can be done. With component teams, you may need to do a form of acceptance testing of the components followed by integration testing of the integrated components before you can conduct readiness assessment. This will be easier to do if you have been doing design reviews of each of the components and have defined clear interfaces and acceptance criteria.
Some of the acceptance criteria may be derived from enterprise requirements. Where enterprise architects exist, it is important to engage them early in the product development lifecycle to ensure you understand what standards the product needs to comply to, what reusable components are available and/or are expected to be used and what enterprise data impacts the product (and vice versa.) This will avoid nasty surprises during readiness assessment and acceptance testing.

Assessing Readiness