1 Overview

The purpose of the Overlord:DTG (Design Time Repository) sub-project is to provide Design Time Governance solutions.

This paper is intended to document concepts and data models that can be used as the basis for the Overlord:DTG user interface.

My goal for Overlord:DTG is to support both top-down and bottom-up design and development of business solutions, as well as various additional features of Design Time Governance such as:

• Artifact Lifecycle Management
• Dependency Analysis
• Impact Analysis

2 Definitions

The following section lists the core concepts found in Overlord:DTG and their definitions.  See Appendix 1 below to see where these concepts have been sourced.

BusinessProblem:  A description of a problem faced by the business that includes a definition of a desired outcome or benefit.

Solution:  A description of how to leverage assets (people, processes, services) to achieve the desired outcome defined by a business problem.

Service: A logical representation of a repeatable activity that has a specified effect.

Task: An atomic action, performed by a human actor, which accomplishes a defined result.

Composition: The result of assembling a collection of things for a particular purpose (e.g. a collection of more granular IT Services to produce a more coarse grained business Service).

HumanActor: A person or organization that can perform a Task.

Event: Something that happens, to which something else can respond.

Rule: A rule that defines or constrains some aspect of the business.

ServiceContract: Defines the terms, conditions, and interaction rules that participants interacting with a Service must agree to (directly or indirectly).

ServiceInterface: Defines the way in which participants of a Service (consumers and producers) can interact with it.

InformationType: The information accepted or returned by a Service.  This is often thought of as business data/models.

ServiceComponent: The implementation (or “realization”) of a Service.  This is typically the actual software code written and deployed to some production runtime environment.

CompositionComponent: The implementation (or “realization”) of a Composition.  This is typically the actual software code written and deployed to some production runtime environment.

DeploymentUnit:  A bundle consisting of one or more ServiceComponent or CompositionComponent.  This typically represents a real artifact produced by a developer that contains the implementations of Services and/or Compositions.

BusinessRequirements: A description of what must be delivered to provide business value.

Documentation: Knowledge about a thing.

3 Data Model

Each item in this represents a concept and is modelled as an Artifact in the Service Repository. Properties are listed first and in normal font.  Relationships to other artifacts are then listed in italic font, with a cardinality description and relationship target type.

• BusinessProblem
  • name
  • description
  • domain
  • definedBy[1:1] → BusinessRequirements
  • documentedBy[1:*] → Documentation
  • solvedBy[*:1] → Solution
• Solution
  • name
  • description
  • documentedBy[1:*] → Documentation
  • solves[1:*] → Business Problem
  • involves[1:*] → Service, Task, Composition, HumanActor, Event, Rule, InformationType
• Service
  • name
  • description
  • documentedBy[1:*] → Documentation
  • hasContract[1:*] → ServiceContract
  • hasInterface[1:*] → ServiceInterface
  • performedBy[1:*] → ServiceComponent, Composition
  • composedBy[*:*] → Composition
• Task
  • name
  • description
  • documentedBy[1:*] → Documentation
  • doneBy[1:*] → HumanActor
  • composedBy[*:*] → Composition
• Composition (ServiceComposition, Process)
  • name
  • description
  • compositionPattern [Orchestration|Choreography|Collaboration]
  • documentedBy[1:*] → Documentation
  • orchestratedBy[1:1] → CompositionComponent
  • composes[1:*] → Service, Task, Event, Rule
• HumanActor
  • name
  • type [person, group]
  • does[1:*] → Task
• Event
  • name
  • description
  • documentedBy[1:*] → Documentation
  • generatedBy[1:*] → Service, HumanActor, Composition
  • composedBy[*:*] → Composition
• Rule
  • name
  • description
  • documentedBy[1:*] → Documentation
  • appliesTo[1:*] → Service, Task, Composition
  • composedBy[*:*] → Composition
• ServiceContract
  • name
  • description
  • interactionAspect
  • legalAspect
  • documentedBy[1:*] → Documentation
  • isContractFor[1:*] → Service
• ServiceInterface
  • name
  • description
  • documentedBy[1:*] → Documentation
  • isInterfaceOf[1:*] → Service
  • hasInput[1:*] → InformationType
  • hasOutput[1:*] → InformationType
• InformationType
  • name
  • description
  • isOutputAt[1:*] → ServiceInterface
  • isInputAt[1:*] → ServiceInterface
• ServiceComponent
  • name
  • performs[1:*] → Service
  • deployedBy[1:1] → DeploymentUnit
• CompositionComponent
  • name
  • orchestrates[1:1] → Composition
  • deployedBy[1:1] → DeploymentUnit
• DeploymentUnit
  • name
  • description
  • deploys[1:*] → ServiceComponent, CompositionComponent
• BusinessRequirements
  • name
  • description
  • requirementsDocument
  • defines[1:1] → BusinessProblem
• Documentation
  • content
  • documents[1:*] → <any>

4 Examples

The following example assumes that the ‘business’ in question is a university - specifically the IT department of a university.  Please refer to the Overlord:DTG - Scenarios document for further details regarding the specifics of this example (reading the scenarios document will reinforce and illuminate the content below).

BusinessProblem: Email accounts must be provided to all university faculty, staff, and students.

BusinessRequirements: The specifics regarding how email accounts will be provided include:

• Students should be provided with a basic email account at the lowest possible cost.
• Faculty and Staff require email and calendaring.
• Accounts should be created as soon as a person joins the University.
• Accounts should be disabled whenever a person leaves the University.
• Additional email accounts can be requested and, if appropriate, provided by the Help Desk.
• Additional email accounts will be granted only for Department heads.

Solution:  The following assets will be used to provide email accounts:

• Google Apps for Education (Cloud Service)
• Microsoft Exchange (Internal IT Service)
• University Email Service (Service Composition)
• Onboarding (Event)
• Offboarding (Event)
• StudentGetsGoogle (Rule)
• NonStudentGetsExchange (Rule)
• HelpDesk (HumanActor)
• CreateDepartmentalAccount (Task)
• EmailAccount (InformationType)

Service: The following Services will be created and/or utilized as part of the Solution:

• Google Apps for Education - A Cloud service provided by Google.
• Microsoft Exchange - Software installed and managed internally by the University IT organization.
• University Email Service (note: this is also a Composition) - A Service that composes the Google Apps for Education and Microsoft Exchange services into a single Email Service for the University.

Task: The following Task will be defined as part of the Solution:

CreateDepartmentalAccount - since these must be requested by the head of the department, they are not automatically created.  Rather, these accounts must be created by a HumanActor on-demand when requested by a Department Head.

Composition: In order to provide a single mechanism by which email accounts are created, a Service Composition is created - the UniversityEmailService.  This will create a Composition consisting of both the Google Apps for Education and Microsoft Exchange Services.  It will hide the details of the Rules driving what specific type of email account is created when a request is made.

HumanActor: The only HumanActor specified in the Solution is the HelpDesk.  The HelpDesk actor is reponsible for doing the “CreateDepartmentalAccount” Task.

Event: There are two events leveraged by the Solution - the Onboarding and Offboarding Events (who or what generates these events is not defined, for simplicity).  When the Onboarding Event is generated, the UniversityEmailService is invoked to create an email account.  When the Offboarding event is generated, the UniversityEmailService is invoked to disable an email account.

Rule: There are two business Rules that are defined and used by this Solution.  Both rules are used by the UniversityEmailService Service Composition when composing the Google and Exchange Services.

• StudentGetsGoogle - if the owner of the requested email account is a student, then the Google Apps for Education Service is used.
• NonStudentGetsExchange - if the owner of the requested email account is not a student, then the Microsoft Exchange Service is used

ServiceContract: Each of the three Services listed will have a defined ServiceContract which will describe, for example, the SLA associated with the Services.

ServiceInterface: Each of the three Services listed will share a common ServiceInterface (EmailService), which will specify/describe (at a minimum) the “create” and “disable” operations.  It will also specify the InformationType returned (output) by the Service as “EmailAccount”.

InformationType: A definition of the EmailAccout information type (the only information type used in the Solution) will include the data properties that make up an Email Account.  Examples include owner, type, quota, created-date, modified-date, etc...

ServiceComponent: The services (Google Apps for Education Service and Microsoft Exchange Service) will require functional implementations:

• Google Apps for Education Service - A Java web service (e.g. Switchyard) is created that implements the EmailService interface and makes calls to the Google Apps cloud service using the Google Apps Java API.
• Microsoft Exchange Service - A Microsoft WCF web service that implements the EmailService interface and makes calls to (consumes/delegates to) the Microsoft Exchange Web Services.

CompositionComponent: There is a single Service Composition that presents a single unified EmailService to consumers, and is called UniversityEmailService.  This is implemented as a WebMethods service, implementing the EmailService, and providing a flow that delegates to either the Google Apps for Education Service or the Microsoft Exchange Service depending on the result of the StudentGetsGoogle and NonStudentGetsExchange Rules.

DeploymentUnit:  There are three deployment units in this example because our two Services and our one Composition are all built using different technologies.  The three deployment units are:

• A Switchyard JAR file containing the Google Apps for Education Service, suitable for deployment to a Switchyard runtime environment (e.g. JBoss 7.1 with Switchyard installed).
• A compiled DLL file containing the Microsoft Exchange Service, suitable for deployment to a Microsoft WCF runtime environment (e.g. IIS 7).
• A Web Methods Package, built and managed through the Web Methods interface, resulting in a ZIP suitable for deployment into a Web Methods runtime environment.

Documentation: Many (if not all) of the above constructs will have pieces of documentation associated with them.  This may simply take the form of Open Office documents or PDFs that further describe the thought processes and decisions behind each.

5 Top-Down Design/Development

One of the styles of design/development is referred to as top-down.  In this style of design, problems are first fully defined (typically by a business analyst), then a solution is architected (e.g. by a SOA Architect), before an implementation is finally coded (by developers).

The Overlord:DTG project will provide a user interface to the Service Repository that will allow users to design their solutions in this fashion.  Users will be able to do the following activities, in the following order:

1. Define and Document a Business Problem
2. Create an empty Solution and link it to the Business Problem
3. List the Business Assets (Services, Tasks, HumanActors, etc...) that will make up the Solution
4. Design and Document the Services, Compositions, Tasks, Rules, Events, etc...
5. Deploy implementations (ServiceComponents, CompositionsComponents, etc) for the above

6 Bottom-Up Design/Development

Some organizations may take a different approach to designing and developing their assets (e.g. Services) where they decompose existing (often legacy) functions then package and release them as standalone (modular, composable, re-usable) Services.  These Services can then later be used to solve future Business Problems.  This style of design is often referred to as bottom-up design.

The Overlord:DTG project will provide a user interface to the Service Repository that will allow users to design their solutions in this fashion.  In particular, it will provide a way to manage Services and implementations of Services (ServiceComponents) without those Services being part of a particular Solution.  This should be considered more of a SOA Developer perspective into the Service Repository (where a Developer often is not concerned with how granular Services are used within larger Solutions to Business problems).

The application will allow Developers to do the following (this list is illustrative, not exhaustive):

• Deploy implementations (ServiceComponents) into the Service Repository
• Manage the lifecycle of the deployed ServiceComponents
• Create and Document the Services that are provided by the deployed implementations
• Manage dependencies between ServiceComponents
• Manage dependencies between Services
• Perform what-if style Impact Discovery (e.g. what will be affected if I delete Service X?)

Appendix 1 - References

Note that many of the concepts and definitions outlined in this document are far more thoroughly described by the Open Group.  One of the goals of Overlord:DTG will be to align as closely as possible with the following:

• The Open Group SOA Source Book[1]
• The Open Group Reference Architecture Technical Standard[2]
• The Open Group SOA Governance Technical Standard[3]
• The Open Group SOA Ontology Technical Standard[4]

[1] http://www.opengroup.org/soa/source-book/intro/index.htm

[2] http://www.opengroup.org/soa/source-book/soa_refarch/index.htm

[3] http://www.opengroup.org/soa/source-book/gov/index.htm

[4] http://www.opengroup.org/soa/source-book/ontology/index.htm

Appendix 2 - Concept Sources

This appendix explains the source for each of the concepts included in this document.  The purpose is to show how this document aligns with the Reference material listed above.

BusinessProblem:  Informal concept discussed in various sources above. [1]

Solution:  Informal concept discussed in various sources above. [1]

Service: SOA Ontology [4]

Task: SOA Ontology [4]

Composition: SOA Ontology [4]

HumanActor: SOA Ontology [4]

Event: SOA Ontology [4]

Rule: Non-formalized concept from the SOA Reference Architecture [2]

ServiceContract: SOA Ontology [4]

ServiceInterface: SOA Ontology [4]

InformationType: SOA Ontology [4]

ServiceComponent: SOA Reference Architecture [2]

CompositionComponent: No source - defined by this document.

DeploymentUnit: SOA Reference Architecture [2]

BusinessRequirements: Informal concept discussed in various sources above. [1]

Documentation: Generic concept.