1. What would be the key artefacts that need to be delivered when defining a solution architecture?
Key artefacts present
different views on solution design where each view is targeting specific
user groups. For example:
- Business architecture
artefacts address business users, planners and business stakeholders.
- Data architecture
artefacts address database and system administrators.
- Application
architecture artefacts provide guidelines and instructions for software
development and test teams.
- Technology
architecture artefacts are essential for infrastructure administrators,
development team and system managers.
- Security architecture
artefacts address the development and test teams, system administrators,
security auditors, business users and managers.
Solution architecture artefacts also
depend on methodology used by an organisation that the solution is designed for.
Popular methodologies include but not limited to TOGAF, Zachman, RUP, CMMI,
FEAF. Examples of key artefacts could
be:
- TOGAF:
- Catalogues (role
catalogue, product catalogue, data entity catalogue, etc)
- Matrices (business
interaction matrix, actor/role matrix, system data matrix, etc)
- Core and extension
diagrams (functional decomposition diagram, use case diagram, process flow
diagram, event diagram, product lifecycle diagram, data security diagram, etc)
- Zachman:
- Practically
sufficient subset of Lists, Models, Diagrams, Specifications and Details
documents that are based on 30 views of Zachman framework matrix –
Why/How/What/Who/Where/When by Contextual/Conceptual/Logical/Physical/Detailed.
2. What would be the role of Solution Architect during the project lifecycle?
Solution Architect’s activity during the
project lifecycle should be organically coupled with business stakeholders’
decision making, development team/s delivery progress and the end users
expectations to ensure:
- Target architecture
would accommodate any possible evolution of the business stakeholders’ vision
of the future system.
- Development teams would follow the architectural guidelines without sacrificing quality,
robustness and effectiveness of the future system.
- The end users have an
early access to the system-in-development, play with it, test it and provide
feedback to architecture and development teams.
It always a good idea to keep architecture
artefacts such as definitions, models, diagrams, specifications, etc updated
during the project to make sure they could be re-used in the future by the
business users, help desk and system support staff.
3. How would a Solution
Architecture work in the context of Waterfall and Agile methodologies?
Once all business requirements are
clarified and understood, a typical search for a solution may include such
activities as reviewing competitive technologies, evaluating open and
commercial off-the-shelf products, building and testing prototypes, etc. In
some organisations it’s called Research and Development (R&D) stage. The
output of R&D stage is a solution design that is (or at least very close to)
target architecture that would be eventually defined in such documents as
Architecture Document mentioned above.
Waterfall methodology is acceptable in
cases when business decision about future system is final and a chance for any
changes is very low. In this case R&D stage is paramount for the whole
project as the solution architecture artefacts would be translated into project
management timelines, delivery milestones, QA test case scenarios and system
releases. Given the importance of R&D, it would make sense to spend more
time on avoiding any ambiguity during reviewing business, functional and
non-functional requirements, looking for possible issues with off-the-shelf
products and stress-testing prototypes to ensure a delivery of a flawless
solution.
Agile methodology doesn’t require
absolutely complete set of requirements, giving it a chance to evolve during
the system development. From high-level perspective, an agile project could be represented
as follows:
The straight lines coming from the centre
(epicentre) are individual use cases, circle lines are delivery milestones and
the red spiral line is actual system development that ‘covers’ use cases (and
milestones) more and more with each iteration until all of them are done (or
delivered). In this case the core system functionality (area around the epi-centre)
is paramount and requires clear prioritisation by the solution architect.
Because of project agile nature, it is expected that solution architecture
artefacts would evolve during the project and therefore should be continuously
updated by the architect and those changes propagated through all teams
involved into the product delivery.
4. What process steps would be expected between
the capture of requirements and start of the coding?
These steps may depend on architecture
methodology used in the organisation (TOGAF, RUP, Zachman, etc) as well as the
type of given project (waterfall or agile). They may include:
- Business, functional
and non-functional requirements review and clarification.
- Business requirements
update (see Guideline for Business Requirements mentioned above) and their
verification with business users. These steps would help to build with business
users unambiguous project vocabulary, learn more about their expectations,
identify key people in their team and establish working relationships with
them.
- R&D stage –
please, see (3) for more details.
- Initial solution
design.
- Verification of
acceptability of proposed solution for existing or target infrastructure.
- Cross-check of
proposed solution design with budget requirements.
- Validation of
proposed solution design against system security constraints.
- Validation of
proposed solution design against internal and/or external rules and
legislation.
- Approval of solution
design with key stakeholders.
- Final (or semi-final
in case of agile) solution design.
- Creation of solution
architecture artefacts - please, see (1) for more details.
- Definition of
development environment. This may include continuous integration and automated
testing, knowledge management system, issue tracking system, network topology
(in case of delivering a Cloud-based solution), etc – this is a range of
approaches that would allow to keep development process transparent to the
architecture team as well as to other interested parties involved in the
project.
- Requirements for
system test coverage.
