|
This section explains how to use The
Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM)
to develop architectures for service-based solutions in SOA.
A solution architecture is a description of a
discrete and focused business operation or activity
and how information technology supports that operation. It is different from
an enterprise architecture, which crosses multiple systems and functional groups.
Although TOGAF
is a framework for developing enterprise architectures, it
can also be used for solution architectures.
This is not a self-standing description. It assumes knowledge
of TOGAF, and leaves out everything that is not related to SOA.
To follow it, you must know about TOGAF.
You can find all the information you need on the TOGAF website.
You may also find it useful to read the section on Using TOGAF for Enterprise SOA
before reading this section.
 The Preliminary Phase
Most solution architecture developments are conducted in the context
of an existing enterprise architecture. The preliminary phase work
has then been done in the preliminary phase
of the development of that enterprise architecture.
There is generally no need to re-visit it for the solution architecture.
If, however, you are just starting to use SOA, and have not
yet developed your SOA at the enterprise level, you do need to do
some of the preliminary phase activities for your solution architecture.
You should treat your solution as a pilot SOA project, and:
Once you have gained experience of SOA from your pilot project (or projects),
you should conduct an enterprise architecture development to establish SOA for
your enterprise, as described in Using
TOGAF for Enterprise SOA. You should also review and modify your governance regime
as necessary, as descibed in Introduction
to SOA Governance and related sections.
Architecture Requirements Management
As for enterprise SOA, architecture requirements management
is not significantly altered for SOA Solutions.
Phase A: The Architecture Vision
TOGAF Phase A includes setting the scope of the architecture development,
describing the vision, and identifying stakeholders and their concerns.
The scope of a solution architecture development is narrow and
focused, as compared with what you would consider in Phase
A of an enterprise architecture development.
It concentrates on the particular solution concerned, and
typically specifies the implementation in some detail.
The high-level description of the final architecture that
is produced as part of the Architecture Vision for a SOA solution
should highlight the kinds of service that will
be produced, the way that they will support the business processes,
and the business benefits that will flow from this approach.
The requirements to address, the stakeholders to consult, and the
models and views to develop, vary from one solution to another.
The section on addressing
stakeholder concerns in SOA lists some areas
of concern that you are likely to encounter in a SOA enterprise or solution
architecture development. If you are working on a solution within an existing enterprise SOA,
concerns relating to the infrastructure should have been adressed already
in the enterprise architecture development. You should focus on areas of concern
relating directly to your solution.
Phase B: The Business Architecture
In the business architecture phase of a SOA solution architecture development,
you should consider the same models as you would for Phase B
of a SOA enterprise architecture development, but at a
level of detail sufficient to enable solution implementation.
- Business Process Model
This is a set of diagrams that show the business processes and their decomposition,
their interactions, and the information with which they are concerned. For an enterprise
architecture, these might show the top-level business processes and, perhaps, one
level of decomposition. For a SOA solution architecture you should
go deeper: perhaps to three or four levels of decomposition.
- Business Roles Catalog
This is a list of the human and organizational users of the system.
They are potential consumers of the portfolio services.
It should include all the users that appear in the solution's business process model.
- Business Vocabulary
This is a list of the key terms used in describing the
business processes and information. For an enterprise architecture development,
this might include only the key terms of the top-level business processes.
For a SOA solution architecture, it should include the key terms of all the
business processes of the solution's business process model.
- Business rules catalog
This is a list of business rules, including rules related to organizational governance.
For an enterprise architecture development, you might only identify the rules.
For a SOA solution architecture, you should generally describe them in more detail.
- Business Services Catalog
This is a list of the enterprise's business services showing
their providers, their potential consumers,
the effects that have value to the consumers, and the service contracts.
As with the business process model, this should go to a more detailed level
of decomposition for a SOA solution architecture than for an enterprise architecture.
Where the solution is developed within the context of an
existing enterprise architecture, the solution models are generally
extensions of the enterprise models, rather than separate models. For example,
the enterprise business process model might show the top-level business
processes with one level of decomposition. Each solution architecture
would then take that model to further levels of decomposition for its
particular functional domain.
Phase C: The Information Systems Architectures
As for Phase C
of an enterprise architecture development, the main impact of SOA on Phase C
of a solution architecture development is on the Applications Architecture
sub-phase rather than the Data Architecture sub-phase.
As for Phase B,
you should consider the same models as you would for
a SOA enterprise architecture development, but at a
level of detail sufficient to enable solution implementation.
In some cases this means a greater level of detail.
In others, the enterprise architecture models suffice
for the solution and do not require further development.
- Service Interaction Model
This is a set of diagrams that show portfolio services, the interactions between them,
and their use of data. For an enterprise architecture, this might show high-level
groups of services. For a SOA solution architecture you should identify individual services.
- Business Process/Service matrix
This shows which business processes include which portfolio services.
The business processes should be those identified in the detailed
decomposition in Phase B, and the services should be
those shown in the service interaction model.
- Service Consumers Matrix
This shows which humans and external systems
consume which portfolio services, interfacing via which portals, channels, etc.
The level of detail should match that of the business process and
service interaction solution models.
- Service Contract and Policy Catalog
This is a catalog of service contracts, and policies for service contracts.
For an enterprise architecture, this might list generic contracts and policies
that apply to different types of service. For a SOA solution, you should
identify the specific policies and contracts that apply to each service.
- Service Access Control Model
This is a set of diagrams that show how access to services is controlled.
If you are developing a solution in the context of an existing enterprise architecture,
that architecture should include a service access control model, and you should in general
not need to develop a specific one for your solution. However, you should check that
the enterprise service access control model is appropriate and adequate.
- Service Configuration and Provisioning Model
This is a set of diagrams that show how services will be configured and provisioned with resources.
If you are developing a solution in the context of an existing enterprise architecture,
that architecture may include a generic service configuration and provisioning model,
but in many cases you may need to develop a specific model for your solution.
- Service Loading Model
This is a model that shows expected loading on services,
including time patterns for service use.
If there are performance concerns, then you will need to develop a
specific service loading model for your solution.
- Service/Applications Matrix
This shows which service building blocks result from
“wrapping” which applications.
For some SOA solutions, there will not be any “wrapped”
applications, and for others there may only be a single application
that is “wrapped”. In these cases, a matrix will not be
needed. But a solution sometimes involves “wrapping”
of multiple services, and you should then produce a solution
service/applications matrix.
Phase D: The Technology Architecture
If you are developing a solution in the context of an existing enterprise architecture,
then in general you do not identify new infrastructure; you show
how your services use the infrastructure of the enterprise technology architecture.
If this is a pilot SOA solution, then you will need to define new infrastructure
for it. You should keep this as simple as possible, and leave
full SOA infrastructure definition to a subsequent enterprise architecture development.
In either case, you should consider the same models as you would for Phase D
of an enterprise SOA development.
- Technology portfolio
This is a catalog of products and kinds of product that will be used in the implementation,
including SOA run-time infrastructure, SOA development environment,
service component technology, and service interface (portal, channel, etc.) technology.
If you are developing a solution in the context of an existing enterprise architecture,
then you should usually not need to change the enterprise technology portfolio and,
if you find that you do need to change it, you should consider re-visiting Phase D
of the enterprise architecture development, rather than making the change as part of
the solution architecture.
- Service/Physical System Matrix
This shows which physical systems host the programs that perform the services.
You should show which physical systems host the programs of your solution.
- Service/Technology Matrix
This shows which items in the technology portfolio are used in the performance of which services.
You should show which items are used in the performance of which services of your solution.
Phase E: Opportunities and Solutions
The Opportunities and Solutions phase identifies delivery vehicles
(projects, programs, or portfolios) that effectively deliver the target architecture
defined in previous phases. For a SOA solution architecture, this is generally simpler than for Phase E
of an enterprise SOA development. It is quite likely that there
will be existing enterprise solution and service portfolios, and you will need
just a single implementation project that will add your solution and its
services to these portfolios.
Phase F: Migration Planning
This phase results in a detailed plan, produced in cooperation with departments
responsible for concerned enterprise activities (such as sales and production, delivery, etc.),
for the implementation of the architecture. This is generally much simpler
for a solution than for Phase F
of an enterprise SOA development.
Phase G: Implementation Governance
This phase involves participation of architects in implementation governance,
to improve the quality of the implementations generally,
and in particular to ensure conformance with the architecture.
A solution architect may be more directly involved in implementation than
an enterprise architect is during Phase G
of an enterprise SOA development. It is also possible that enterprise architects are
involved in solution implementation governance.
See the Introduction
to SOA Governance and related sections of this Source Book for further information
on SOA governance.
Phase H: Architecture Change Management
Phase H is concerned with reviewing and updating the architecture
and the architecture process itself.
For a solution architecture developed within the contect of an existing
enterprise architecture, this can include assessing the performance of the
enterprise architecture and making recommendations for changing it.
Phase H of a SOA pilot solution architecture development could produce
recommendations for adoption and development of enterprise SOA.
|
You are here:
