This project is read-only.

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:
  • conducting architectural reviews and audits; evaluating architectural alternatives;
  • ensuring the use of agreed-upon architecture and design practices;
  • ensuring that architectural documents are useful, up-to-date, and sufficiently complete;
  • making documentation trade-off decisions;
  • planning architectural migration;
  • and coordinating and communicating with architects and other stakeholders regarding architectural governance, compliance, and policy matters.
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

  • As solution architect, you will likely be asked for your opinion as to whether the product is ready for acceptance testing. You’ll want to make this recommendation based on hard data and will therefore want to conduct architecture reviews and security code inspections and to run static code analysis and coverage tools. You will also want to understand how well the non-functional characteristics of the system comply with the requirements; that will require testing of the non-functional characteristics. You may be involved in the actual testing, either in person or through planning and delegating, or you may review results provided by someone else such as the test organization. Either way, you will want to ensure that the system meets any operational requirements, including SLAs, in addition to the functional requirements.

Last edited Nov 5, 2009 at 11:36 PM by rburte, version 1

Comments

No comments yet.