Using TOGAF to Define and Govern Service-Oriented Architectures – Relations to the SOA Work Group Projects
The Platform Service and the Platform Model created in Phase D define the platform functional and non-functional requirements of the architecture. They define the SOA Reference Architecture capabilities needed. These requirements are used to instantiate the SOA Reference Architecture. It would be a good idea to iterate between the IS Services (process, application, and data) and the SOA Reference Architecture capabilities to make sure that the correct capabilities are defined together with the non-functional requirements for those capabilities.
The Business Services gives the service Portfolio Management a first idea on possible SOA services.
The Logical Application Components define the SOA service requirements at a more detailed level of granularity. Both Business Services and Logical Application Components are used by the SOA Governance – Service Portfolio Management process to plan the long-term portfolio of SOA services for the organization.
The Physical Application Component Model describes the future application landscape. Each Physical Application Component describes a component (e.g., SOA service) of a possible future SOA solution. The SOA solution consists of one or more Physical Application Components.
The security requirements are first defined in Phase B on both the Business Services and the Contracts between the Business Services. These security requirements are then transposed into the security requirements on the IS Services and subsequently on the Platform Services.
The security requirements are then input to a detailed design phase (part of implementation projects) for both the SOA solutions and the SOA Reference Architecture.
The Processes, Business Services, and Information System Services define the requirements on the legacy systems.