4.1 Scenario - Full SOA Project Lifecycle

The following series of sub-scenarios describe the full lifecycle of a new SOA project managed using Overlord:DTG.

4.1.1 Project Initiation

4.1.1.1 Background

The organization has identified a new Business Problem that requires a technical Solution.  In this case, and for the next few scenarios, a University has decided to offer email accounts to all students, faculty, and staff.  It has been determined that, for cost reasons, all students will receive email via a cloud based email provider.  However, for compliance reasons, all faculty and staff will receive internal email accounts.  Everyone will receive an email account when they first become affiliated with the University (when hired or matriculated).  Email accounts will be deleted when their owners leave the University.  Finally, shared Departmental email accounts are available upon request to the Help Desk (only Department Heads can request these).

4.1.1.2 Participants

• Patty [Project Manager]
• Beth [Business Analyst]

4.1.1.3 System Narrative

Patty logs into the system and creates a new Business Problem, giving it a name of “Email for Everyone” and a domain of “ITS”.  Once created, she grants Beth access to the Business Problem by granting Beth the role of “Business Analyst” for the Business Problem.  Beth receives a notification informing her of her new role, and providing a web link to the new Business Problem.

Beth logs into the system and navigates to the newly created “Email for Everyone” Business Problem (possibly via the web link from above, or else by choosing it from a list of Business Problems available to her).  Over the next few days, Beth creates the Business Requirements for the Business Problem and populates it with information and decisions made by the business leaders.  Decisions are typically gathered over time during a series of meetings with relevant stakeholders.

4.1.2 Solution Design

4.1.2.1 Background

The Business Problem has been defined and documented, and now it’s time for the Architect to design the technical Solution.  Based on the Business Requirements and analysis of existing and future technical assets, it is decided that all students will receive Google Apps for Education accounts while faculty and staff will receive Microsoft Exchange accounts.

4.1.2.2 Participants

• Patty [Project Manager]
• Arlen [Architect]

4.1.2.3 System Narrative

Patty logs into the system and creates a new Solution for the “Email for Everyone” Business Problem.  She then grants Arlen access to it by granting him the “Architect” role for the Business Problem and Solution.  Arlen receives a notification informing him of his new role, and providing a web link to the new Solution.

Arlen logs into the system and identifies all of the technical assets that will be needed to implement the technical Solution.

• The Microsoft Exchange Service already existed from another project, so Arlen adds it as an asset to this Solution.
• Arlen creates a new asset for the Google Apps for Education Service, which does not yet exist and must be defined and implemented.
• Arlen creates two new Rules (StudentGetsGoogle and NonStudentGetsExchange) and adds them to the Solution.
• Since this is the first time multiple email Services are needed, Arlen decides to create a new Composition asset that will compose the Microsoft Exchange Service and Google Apps for Education Service into a single entity (along with the Rules defined above).
• Arlen then creates a new University Email Service (that will be “provided by” the above Composition).
• Arlen defines the ServiceInterface and ServiceContract artifacts for each of the Services mentioned (the Services may share either ServiceInterfaces or ServiceContracts or both)
• The “PersonOnboarded” and “PersonOffboarded” Events already existed from another project, so Arlen adds them to the Solution.
• Since the “Help Desk” HumanActor is a common participant in Solutions to Business Problems, it was already defined - so Arlen adds this existing asset to the Solution.
• A new Task that the Help Desk will be performing is the CreateDepartmentalEmailAccount Task, so Arlen creates this new Task and adds it to the Solution (indicating that the Help Desk HumanActor “does” this new Task).
• Arlen creates a new InformationType named “EmailAccount” that defines the data properties that comprise an email account.

Note: as Arlen makes changes to the Solution, notifications may be sent to Patty and Debbie.

4.1.3 Solution Implementation

4.1.3.1 Background

The Architect has defined the Solution to the Business Problem.  The next step is to implement the Solution, a task that is performed primarily by the Developer role.

4.1.3.2 Participants

• Patty [Project Manager]
• Arlen [Architect]
• Debbie [Developer]

4.1.3.3 System Narrative

Patty logs into the system and grants Debbie access to the “Email for Everyone” Business Problem and Solution by granting Debbie the “Developer” role.  Debbie receives a notification informing her of her new role, and providing a web link to the Solution.

Arlen logs into the system and indicates (within the Solution) which of the assets requires an implementation.  Note that in some cases implementations are not required, for example Tasks may not require technical components.

Debbie logs into the system and reviews the Solution designed by Arlen.  Debbie works with Arlen to finalize all ServiceInterfaces and ServiceContracts.  Debbie and Arlen work together to produce implementation artifacts for all ServiceInterfaces and InformationTypes (i.e. WSDLs and XML Schemas).  Debbie creates these implementation artifacts using standard Software Development Tools (outside the system) and adds them to the system, then links them to the appropriate Services.

Debbie uses standard Software Development Tools (outside the system) to implement the ServiceComponents and CompositionComponents needed by the Solution.  This may take the form of Switchyard services, JAX-WS web services, Microsoft WCF services, Web Methods services, etc - depending on the production runtime environments available to her.  When these Components are fully implemented and ready for deployment, Debbie packages them up into one or more DeploymentUnit and adds it/them to the system (either manually through the UI or integration with a build technology such as Maven).

Debbie logs into the system and links the various Components she added above to their respective logical artifacts.  For example, her DeploymentUnit contains a JAX-WS web service for the Google Apps for Education Service defined in the Solution.  She uses the system to link that Google Apps for Education implementation (ServiceComponent) to the Google Apps for Education Service, effectively linking the implementation to the definition in the Solution.  Debbie does this for all Services, Compositions, Rules, etc.

4.1.4 Solution Release

4.1.4.1 Background

Once the Solution design and implementation are complete, the Solution must be released into production.  We focus mostly on the technical mechanics (e.g. deploying Components into production systems) here, but of course there is the opportunity for non-technical release tasks as well (communication, documentation, etc) which may or may not be in-scope for the system at some point.

4.1.4.2 Participants

• Patty [Project Manager]
• Beth [Business Analyst]
• Arlen [Architect]
• Debbie [Developer]
• Tim [Tester]

4.1.4.3 System Narrative

When Debbie pushes her Deployment Unit into the system, a lifecycle management workflow is automatically triggered.

Note: This lifecycle management workflow will guide the Deployment Unit through various states, culminating in a release of the Deployment Unit into the final production runtime environment.  Along the way, it is likely that users will be asked to give approvals.

The Deployment Unit contains the implementation Components for logical assets in the Solution, such as ServiceComponents (e.g. Switchyard services) and CompositionComponents (e.g. WS-BPEL orchestrations).  The system automatically extracts these Components and stores them in the Repository.  Each of these Components must be linked to the logical asset that it implements.

Debbie uses the system to link all Components from the Deployment Unit to their respective logical assets.

Note: The lifecycle management workflow may require the linking of Components as one of the Tasks included in it.  In some cases, the linking between Component and its logical asset (e.g. a Switchyard application and the logical Service it implements) may be automatic.

Debbie uses the system to approve the Deployment Units for release into the development environment. She then uses standard developer and user tools (external to the system) to verify that the implementation works properly in the development environment.  If the implementation is working properly, Debbie uses the system to confirm that the implementation is ready to be tested.  Tim receives an email informing him that the Deployment Units are ready for testing.

Tim uses the system to approve the Deployment Units for release into the test environment.  He then uses standard test and user tools (external to the system) to verify that the implementation works as expected in the test environment.  Tim works with Beth to ensure that the implementation appropriately solves the business problem.  If the implementation is working properly and appropriately, Tim uses the system to confirm that the Deployment Units are ready to be released into production.  Beth receives an email notifying her that the Deployment Units are ready for release to production.

Beth uses the system to approve the Deployment Units for release into the production environment.

Arlen and Debbie use the system to monitor the state of the Deployment Units containing the runtime Components.  Once all Deployment Units are in the “deployed to production” state, Arlen can mark the Solution as “released”.

Note: as changes are made to the various Components and logical assets, notifications may be sent to Patty, allowing her to monitor the state of the Solution..

Once all Deployment Units are released into production, Patty can use the system to mark the Business Problem as “solved”.