CBDI Journal April 2009The CBDI Certification process enables candidates to calibrate and communicate their skill level and allows program and project management to plan more effective

April 2009

Editorial Principles - A prerequisite for effective design. SOA Best Practice Report Agile SOA Is the term “agile SOA” an oxymoron? Many people will see SOA and Agile methods as chalk and cheese, apples and oranges or oil and water - they don’t mix well. In this report we suggest there are many ways in which Agile techniques and methods can be highly effective in delivering services and solutions in the SOA style. By David Sprott

Product Overview OutSystems Agile SOA Platform The OutSystems Agile Platform is a unified software development environment that provides full life cycle support for composing Web business applications using Agile methods. In this report we overview how the combination of product architecture and agile methods are used to deliver SOA based solutions. By David Sprott

Product Report Software AG CentraSite ActiveSOA CentraSite is a SOA governance and lifecycle management product from Software AG. This report looks at how an enterprise user organization may customize and extend the provided capabilities to support the meta model underlying Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports. By Lawrence Wilkes

Independent Guidance for

Service Architecture and Engineering

ISSN 1745-1884

CBDI Journal © Everware-CBDI Inc. April 2009 2

Editorial Principles - A prerequisite for effective design.

There’s a long running broadcasting history radio program on Sunday mornings on Radio Telefis Eirann (the national Irish broadcaster RTE) edited and introduced by John Bowman. The program comprises interesting clips from RTE’s extensive broadcasting archives.

A couple of weeks ago the first item was a piece on Frank Lloyd Wright, the well known American architect1, triggered by the 50th anniversary of his death. The piece recalled several young Irishmen who in 1950, sailed to America to work with Lloyd Wright for a few months.

One of the men, Sean Kenny, recalled that they were rather pleased with themselves having completed a rather adventurous crossing of the Atlantic, and were somewhat taken aback when they first met Lloyd Wright. Expecting to be put to work on architecture related tasks they

were more than a little surprised to be given a pick and shovel and directed to work on the construction of one of Lloyd Wright’s designs. At the conclusion of their stay they recalled they didn’t come away with a deep insight into how to practice architecture. However they did learn a huge amount about the principles of using space in design to create solutions that worked for the user.

Kenny returned to Ireland and related how he set up as an architect. In the first two years he was very disappointed – prospective customers didn’t beat a path to his door, in fact during that period he obtained just one small engagement. Yet in later years Kenny became very well known as a stage and set designer for the Irish theatre.

Once again I return to a common theme. Deep understanding of architectural principles is a prerequisite for effective design. The primary challenge of SOA is interpreting the business goals into architecture that uses relevant principles to deliver an appropriate and affordable level of agility, and then exerting governance over the delivery and ongoing maintenance to ensure the integrity is not compromised.

Deep understanding of architectural principles is a prerequisite for effective design. The primary challenge of SOA is interpreting the business goals into architecture that uses relevant principles to deliver an appropriate and affordable level of agility, and then exerting governance over the delivery and ongoing maintenance to ensure the integrity is not compromised.


But Kenny’s story also suggests that “architecture” shouldn’t always be a discrete activity. Rather it is a way of thinking that will be applicable to many roles and actors in a wider process.

This month, in not unconnected pieces, I write about Agile methods and their relationship to SOA. I am reminded that everything we do is a series of compromises. The issue with Agile methods is that the required compromises often appear unacceptable in context with architectural principles. Yet there are many aspects of Agile methods that can deliver real value to an agile architecture. The key is determining the important business goals and then using architecture principles and patterns that can deliver appropriately. Merely cloaking your activities in “agile methods” is likely to create a suboptimal result. Like Sean Kenny, we all need to understand what represents good architectural outcomes, and then be prepared and indeed capable of picking up our metaphorical picks and shovels and delivering effective solutions.

Finally, regular readers will know that while most of the Journal material is produced by CBDI people, occasionally we publish guest articles. In future I would like to increase this balance of guest material and I would like to invite CBDI members to consider making a contribution to the CBDI Journal. I am interested particularly in members’ experiences that develop and extend the body of Service Architecture and Engineering (SAE) practice guidance. For example practical experiences in service classification, policy setting, governance criteria, use of the SAE meta model and profile etc. If you would like to make a contribution, please contact me to discuss.

David Sprott, Everware-CBDI, April 2009

http://www.cbdiforum.com/feedback.php3

1 Wikipedia on Frank Lloyd Wright http://en.wikipedia.org/wiki/Frank_Lloyd_Wright Understanding the relationship between Style, Concept, Practices and Patterns, David Sprott http://www.cbdiforum.com/secure/interact/2008-06/editorial.php CBDI Forum links: Home: www.cbdiforum.com

Resource Portal: http://cbdi.wikispaces.com/

Forum: http://www.linkedin.com/groups?gid=1464387

CBDI Forum is the research capability of Everware-CBDI providing independent guidance on best practice in service oriented architecture and related delivery processes.



Everware-CBDI Delivers Major Upgrade to SOA eLearning Capability. eLearning portfolio for developing SOA skills across all roles in the organization

• 21 eLearning modules

• Fundamentals and Practitioner levels

• Cost efficient SOA skills development

• For business analysts, architects, designers, developers, testers, governance reviewers and project managers

• Associated certification services

• SCORM compliant modules for hosting in customer Learning Management System

• Available now to CBDI Platinum subscribers in the Knowledgebase

Everware-CBDI announces that it has delivered a major upgrade to its SOA eLearning portfolio. Twenty-one eLearning modules are now available providing both fundamentals and practitioner level education for a broad range of SOA skills. In addition CBDI certification services are available, which together with the eLearning modules, can address critical skills shortages in SOA efforts.

Though many IT architects are very knowledgeable about SOA there remains considerable confusion and inconsistency of practice and process. SOA skills in many organizations are often limited to the architecture role and focused primarily on technology. As a result SOA projects often spend more time and energy determining how to apply SOA concepts than delivering project results.

The new Everware-CBDI eLearning portfolio is designed to equip a broader set of roles including business analysts, architects, designers, developers, testers, governance reviewers and project managers with consistent, detailed understanding of SOA practice. The e-Learning modules allow practitioners to educate themselves when it is convenient for them in a cost efficient manner.

The CBDI Certification process enables candidates to calibrate and communicate their skill level and allows program and project management to plan more effective and consistent resource utilization. There are two certification levels – Fundamentals and Practitioner. The Fundamentals level can be achieved entirely through eLearning and self study. The Practitioner level can be achieved through various combinations of eLearning, self study, remote and face to face classes.

The eLearning and certification products are delivered either as an integral part of the CBDI Service Architecture & Engineering (SAE) Knowledgebase or as standalone executables that can be hosted by the customer. They can also be provided as SCORM-compliant modules so that they can be used within a customer’s Learning Management System. All CBDI Platinum subscribers and Knowledgebase licensees will have immediate access to all the eLearning modules.

More information: Everware-CBDI Education Services - Overview and DataSheets http://cbdi.wikispaces.com/Everware-CBDI+Education+Services

Everware-CBDI eLearning Products – Module Lists http://cbdi.wikispaces.com/eLearning+Products

Contact Everware-CBDI http://www.cbdiforum.com/feedback.php3

http://cbdi.wikispaces.com/Everware-CBDI+Education+Services

http://cbdi.wikispaces.com/eLearning+Products


CBDI Journal © Everware-CBDI Inc. February 2009 5

Agile SOA Is the term “agile SOA” an oxymoron? Many people will see SOA and Agile methods as chalk and cheese, apples and oranges or oil and water - they don’t mix well. On the one hand Agile methods eschew formality, while SOA is inherently about bringing structure and design governance. Yet there is clearly high demand for rapid delivery methods and widespread dissatisfaction with enterprise SOA efforts that are not delivering rapid business value. In this report we suggest there are many ways in which Agile techniques and methods can be highly effective in delivering services and solutions in the SOA style. We provide a framework that clarifies where the various techniques are appropriate and strategies for success in Agile SOA. In a complementary report we also overview the Outsystems product that claims to be an Agile SOA platform.

By David Sprott

Introduction Continuing concerns over the effectiveness of enterprise SOA, together with the recession driving immediate cost reduction and tactical solution delivery projects inevitably creates demand and interest in agile solution delivery methods.

Agile isn’t new. I will admit pioneering Rapid Application Development (RAD) techniques while working with James Martin Associates (JMA) in the 1980s. RAD was a forerunner of today’s Agile methods and blazed a trail for timeboxing, hybrid teams, specialized tools and individual responsibility. Today a number of software development methodologies are clustered under the term Agile methods. These include Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM) and V-Model. Agile methods are a family of development processes, not a single approach to software development. Most agile methods include iterative and incremental development approaches and focus on building releasable software in very short time periods of weeks not months. Working practices are generally collaborative and formal documentation is less important than delivered working software. Some questions we will attempt to answer:

• How does Agile (software development) relate to SOA?

• Do Agile practices relate purely to software development?

• Is there a concept that we might refer to as Agile SOA?

There are many areas where Agile methods can be very productive and complementary with SOA . . . however the relationships are not simple or straightforward, varying by SOA Process Unit, class of service, levels of standardization and reuse


In this report we will analyze the commonly used Agile techniques and practices and consider applicability to SOA processes. We will attempt to provide a framework that clarifies where the various techniques are appropriate and strategies for success in Agile SOA. In a related report we overview the Outsystems product as an example of an Agile SOA platform.

Agile In Brief Scrum1: In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach for commercial new product development. Scrum is described as a "process skeleton," which contains practices and predefined roles. They compare this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, to the game of rugby, where the whole team attempts to work as a unit, passing the ball back and forth.

• Defined Roles – ScrumMaster, Product Owner, Team

• Sprint – time-boxed period typically a 2 – 4 week period

• Self organizing teams

• Co-location

• Verbal communications

• Empirical (observed) approach with expected requirements churn

Crystal Clear2: a member of the Crystal family of methodologies as described by Alistair Cockburn based on observations of many successful teams. Crystal Clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical with focus on efficiency and habitability as components of project safety. Crystal Clear focuses on people, not processes or artifacts. Key properties:

• Frequent Delivery of Usable Code to Users (required)

• Reflective Improvement (required)

• Osmotic Communication Preferably by Being Co-Located (required)

• Personal Safety

• Focus

• Easy Access to Expert Users

• Automated Tests, Configuration Management, and Frequent Integration

Extreme Programming (XP)3 is a software engineering methodology (and a form of agile software development) prescribing a set of daily stakeholder practices that embody and encourage particular XP values. Created by Kent Beck the methodology takes well known "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s. Rules articulated as rules of engagement and rules of play.


Adaptive Software Development (ASD)4: ASD replaces the traditional waterfall cycle with a repeating series of cycles - speculate, collaborate, and learn. This provides for continuous learning and adaptation to the emerging state of the project. Key characteristics:

• mission focused

• feature based

• iterative

• timeboxed

• risk driven

• change tolerant

Feature Driven Development method5: built around a core set of industry-recognized best practices, derived from software engineering. These practices are all driven from a client-valued feature perspective.

• Domain Object Modeling.

• Developing by Feature. Functionality is decomposed into functions that can be implemented in two weeks

• Individual Class (Code) Ownership. Distinct pieces of code are assigned to a single owner.

• Feature Teams.

• Inspections.

• Configuration Management.

• Regular Builds.

• Visibility of progress and results.

The V-model6 is a software development process which may be used as an extension to the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated testing processes. Testing activities start at the beginning of the project well before coding and, if well structured can save a significant amount of time and resource.

Dynamic Systems Development Method (DSDM)7 Originally based upon the Rapid Application Development (RAD) methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement. Principles include:

• User involvement

• Empowered project team.

• Frequent delivery of products

• Delivering a system that addresses the current business needs.

• Iterative and incremental development driven by users’ feedback

• All changes during the development are reversible.


• The high level scope and requirements should be base-lined before the project starts.

• Testing is carried out throughout the project life-cycle.

• Efficient and effective communication and cooperation among all project stakeholders

Agile Model Driven Development (AMDD)8 AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. In AMDD agile models are created with just enough scope and depth that drive your overall development efforts. With an evolutionary approach detailed modeling is done just in time (JIT) during development iterations in model storming sessions.

• Model Storming: Just In Time (JIT) Modeling

• Agile Architecture Modeling

• Agile Requirements Modeling

Agile Conflicts with SOA? Agile software development cannot be compared directly with SOA. They are two quite different concepts. Agile, as the name suggests, is a software development approach or methodology that promotes techniques and strategies that are proven best practices that, when used appropriately can deliver higher quality software solutions more rapidly. The Agile techniques and strategies will include project management approaches such as timeboxing of small increments, frequent inspection and adaptation and teamwork. Agile methods will prioritize working software as the primary determinant of progress and tend to reduce formality of process and other deliverables in favor of proven techniques such as face to face communication, trust in motivated individuals, self organizing teams and simplicity. The approach is articulated by the Agile community as a set of principles that reflect this tension by identifying relative values as follows:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

While SOA is also a set of principles, it is an architectural style. The key principles are focused on the architecture and design outcomes and will typically include:

• Loose coupled

• Standardized

• Abstracted

• Composable

• Modular

• Virtualized


There is an obvious area of synergy between Agile and SOA in the area of building services where software development methodology is clearly going to be relevant. But there are also obvious conflicts in approach because SOA and services have different objectives and values.

Agile SOA

Software development methodology Planning, architecture, delivery and management of business and software services

Project Scope is single solution Service provisioning is cross-solution in scope

Project scope is single track: solution-centric projects deliver solution and any contained services

Project scope is twin-track: separation of service provision from solution assembly projects

Prioritized working software – delivery focused Prioritized delivery AND evolution incorporating reusable services and contracts

Individuals and interactions – emphasize local concerns

Federated service delivery and usage – emphasize collaborations and broader user community

Enable broader concerns in a standardized context

Customer collaboration – works with limited user community

High quality services should be abstract and able to support many business processes now or in the future

Adaptive Software Development : Responding to change – recognizes the need to deliver on immediate needs

Prepares for change through better architecture and design

Table 2 – Obvious Conflicts

Superficially it might be concluded that Agile methods work when all the potential project management risks and issues are addressed. For example:

• Minimum external dependencies – standalone application

• Minimum performance issues – mainstream performance envelope only

• Narrow, defined user base

• Constrained project scope

• Reliability and security are not critical.

• System can be split into several independent modules.

• The project has strong timebox potential (phases).

• Proven development technology

• Proven delivery technology

• The product is not mission- or life-critical.


Mapping Agile to SOA Given the wide variety of practices that are subsumed under the Agile concept, it makes sense to consider how each of the individual practices, rather than each of the methodology variants, map to SOA.

Agile Practice SOA Relevance

Defined roles Defined roles in general are very important. It’s a great lesson to learn from Agile practices. Agile roles will be useful where Agile practices are used in (solution development) context. Key additional roles include Service Architect, Service Specification Designer9.

Sprint – time-boxed period typically a 2 – 4 week period

Applicable to legacy wrapping and Underlying Service creation. Also Solution Assembly – potential for massive increase in productivity by reuse of common services.

Self organizing teams Solution Assembly

Co-location (osmotic communication)

Applicable to phases of Solution Assembly. But broader project or program using SOA style are likely to be strongly federated. Use of onshore and offshore particularly effective using rigorous service specifications.

Verbal communications Once again applicable to Solution Assembly. Strongly discouraged (as a replacement for formal deliverables) in business modeling, business improvement, service architecture, provisioning and governance. Very difficult to exert effective governance over business integrity and agility with purely verbal communications.

Empirical (observed) approach with expected requirements churn

Applicable to Process (and possibly Capability) Services. Inappropriate for Underlying, Utility and Core Business Services.

The whole process is performed by one cross-functional team across the different phases

Within a Solution Assembly sub project or phase.

Automated Tests, Configuration Management, and Frequent Integration

Strongly recommended. Drive test scripts from rigorous service specification. However in certain (Agile method) instances test scripts are recommended as a replacement for specifications, and this is discouraged – because the form of the test script is actually highly inappropriate for communication of behaviors10.

Test-first development, planning and writing tests before each micro-increment

Strongly recommended for all classes of services. See prior point.

Frequent Delivery of Usable Code to Users

For Solution Assembly only.



Easy Access to Expert Users For Solution Assembly and Process Services.

For other classes of service user selection is important because the services should be more abstract, and less applicable to individual users.

Iterative. Repeating series of cycles - speculate, collaborate, and learn.

In many cases Service Specifications may need to evolve and iteration may be a useful technique. However where this is used great care needs to be exercised to ensure that users of early iterations need to be bought into an SLA that binds them to frequent upgrades in the early stages of use.

Mission focused Strongly recommended. May be both pure business mission focused as well as business agility mission.

Feature based - Functionality is decomposed into functions that can be implemented in two weeks; Feature Teams

More applicable to Process Services, Capability Services and Solution Assembly.

Feature is not generally relevant to Core Business Services and Underlying Services.

Feature perspective could be used to scope the effort on specifying and implementing the individual Operations of Services, by considering an Operation as a ‘feature’. That is, only working on operations for which there is immediate requirement, and limiting the function of the operation to the immediate requirement

Configuration Management Essential

Regular Builds Fully applicable to all build activity, particularly where rigorous test scripts are available plus automated test harness

Visibility of progress and results SOA facilitates smaller components, units of work and integrity, which in turn enable better visibility.

Mandatory update of Registry Repository data also provides excellent visibility and dependency

Timeboxed Good application for Solution Assembly and Process Services.

For all other classes of service the time-box has to be subordinated to delivery to specification, following which each operation may make a candidate sprint, or clusters of operations required immediately may make a candidate timebox.

Similarly a timebox could be used for development of architecture, (see AMDD) but not specifications.

Risk Driven Not for reusable services



Change tolerant Core SOA value and performance measure. At all stages (architecture, specification, automation unit specification, design and build) and all classes of service, agility should be built in appropriately to the business value.

But note this may be radically different to uncontrolled changes of requirement. Use of agility enabling patterns strongly recommended.

Domain Object Modeling Strongly recommended for Process, Capability and Core Business Services. In SAE we advise domain modeling as a mechanism to establish broader stability of abstract service specifications before focusing down on specific requirements, which correlates to FDD very closely.

Individual Class (Code) Ownership. Distinct pieces of code are assigned to a single owner.

Applicable for Solution Assembly. However for other classes of service separation of work packages is ideally done on the basis of class of service, component and or operation.

Inspections Always good practice

V-Model testing - Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. Testing is carried out throughout the project life-cycle

Strong recommendation. See CBDI Report on same topic11 that illustrates how to map V model to provider (left side) and consumer (right hand side)

User involvement Solution Assembly, Process Services and (possibly) Capability Services are straightforward. For other classes of service need to identify cross section of community of users that can inform a more abstract, broadly applicable requirement.

Frequent delivery of products Process Services, Solution Assembly

Delivering a system that addresses the current business needs

Needs to be tempered with the caveat . . . . that can easily be adapted to unforeseen changes in business requirements, model etc

Iterative and incremental development driven by users’ feedback

Essential to factor in the standardization of process, data etc. The primary of a single user is unlikely to be useful. Especially true for services that have a high reusability forecast

All changes during the development are reversible

Significant conflict. SOA is dependent upon stable specifications. Should be replaced with Achievement of stable, high quality specifications is paramount. All changes that impact service specification (interface) must be coordinated and introduced in a manner that balances cost of change and refactoring with meeting immediate business needs.



The high level scope and requirements should be base-lined before the project starts

Very important in the SOA context. However conventional view of scope should be extended to include responsibility for providing and consuming services. This may be achieved from a Service Portfolio, or a preparatory scoping/feasibility study.

Efficient and effective communication and cooperation among all project stakeholders

Very important in the SOA context. Extend stakeholders to include SOA governance, service owners. Extend communications content to ensure deep understanding of the SOA goals relevant to the program or project.

Model Storming: Just In Time (JIT) Modeling

Very useful in the SOA context, however needs to be managed in context with requirement to stabilize baselined scope and service specifications.

Agile Architecture Modeling Same

Agile Requirements Modeling Same

Table 2 – SOA Relevance of Agile Practices

Agile SOA Project Profiles From the analysis in Table 2 it becomes clear there are many areas where Agile methods can be very productive and complementary with SOA. It also becomes apparent that the relationships are not simple or straightforward, varying by SOA Process Unit, class of service, levels of standardization and reuse etc.

To make this complex relationship clearer there are some project profiles that can be usefully identified as recommended approaches. None of these are new ideas.

Contract First Solution Delivery Establish agreed contracts for provision and consumption of services as a preliminary phase of activity. This may be a pilot, feasibility study or pre-project planning activity. Once the usage contracts are agreed it will be practical to plan a variety of Agile projects including Solution Assembly, Solution Delivery and a combination of the two.

Interface (Service Specification) Stabilization As we all know interface stability varies proportionately to the number of times an interface is reused. There is a similar relationship also to the number of parties involved. Achieving stability for key services including core business and capability that will have a high level of reuse may present a high level of difficulty, with attendant risk of fragmentation caused by incompatible project schedules.

I have observed a successful approach to resolving this problem whereby a series of Agile sprints and or projects are executed, at least initially sequentially, which progressively broaden the business scope addressed. All parties to the process plan their work on the basis that the service specification will alter frequently during this process, and work to accommodate change on an ongoing basis.

AMDD (Agile Model Driven Development)


The conflict between SOA and Agile clearly arises because the fundamental purpose of SOA is to establish strong architecture specifically with agility characteristics. And mature SOA needs more than simply Web services interfaces! The AMDD Agile method (see Agile in Brief above) has some considerable applicability therefore to SOA, guiding a narrow path, just enough modeling approach that can avoid the worst of service anarchy.

In SAE we recognize the difficulties of establishing a comprehensive Service Portfolio Plan (SPP) in the early stages, and recommend a Project Service Plan that examines the issues and opportunities from the perspective of the project. If the project is using say CUSTOMER, that may be a tough ask, but if it is using CREDIT, it may be perfectly feasible to establish a broader consensus model which will deliver a useful, reusable service.

RAD Revisited – Tools AND Techniques, Reviewing the Agile methods in use I was struck by the strong emphasis on methods and in contrast the minimal or complete absence of focus on tooling. Most of us will be acutely aware of the criticality of tooling, and the positive impact on productivity if there are excellent tools that automate, not just the delivery process, but management also. In the early days of Agile, the RAD method focused on methods and tools in equal proportion for good reason. I wonder if this important guidance has been lost along the way?

Conclusions I have observed emotive comments on Agile and SOA suggesting they are incompatible. Clearly there are some big issues. If you deliver services purely driven by user stories with limited functional coverage, you are going to get Web services that are process or situation specific. However if you use the aspects of Agile in an SOA context then there are many opportunities. The key to cooperation between the architectural style and the method is not to assume one size fits all. It’s hard to summarize Table 2 in this report. It reflects the complexity of the issue, and the need to be selective.

1 Scrum http://en.wikipedia.org/wiki/Scrum_(development) 2 Crystal Clear http://en.wikipedia.org/wiki/Crystal_Clear_(software_development) 3 XP http://en.wikipedia.org/wiki/Extreme_Programming 4 ASD http://en.wikipedia.org/wiki/Adaptive_Software_Development 5 FDD http://en.wikipedia.org/wiki/Feature_Driven_Development 6 The V-Model http://en.wikipedia.org/wiki/V-Model_(software_development) 7 DSDM http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method 8 AMDD http://www.agilemodeling.com/essays/amdd.htm 9 SAE roles (Knowledgebase Lists) http://www.soakb.com/knowledgebase/Menu/Roles.aspx?View={1E792031-6F79-4A06-934C-9FE6F1B59F4F}&SelectedID=17 10 CBDI Journal Report - Documenting Service Behavior http://www.cbdiforum.com/secure/interact/2007-12/documenting_service_behavior.php 11 CBDI Report – SOA Testing http://www.cbdiforum.com/secure/interact/2008-04/managing_testing.php


Product Overview: OutSystems Agile SOA Platform

The OutSystems Agile Platform is a unified software development environment that provides full life cycle support for composing Web business applications using Agile methods. In this report we overview how the combination of product architecture and agile methods are used to deliver SOA based solutions.

By David Sprott

Introduction OutSystems is a software product company formed in 2001 with offices in Portugal, Benelux and the USA. The company is focused on assisting its customers to dramatically shorten business solution time to delivery. The OutSystems Agile Platform is an integrated set of tools that span the entire life cycle of Web business applications to provide support for an Agile approach based on a variant of the Scrum1 method adapted to the enterprise environment.

The Agile Platform is industry sector neutral; customers include utilities, telecoms, finance and insurance, life sciences, retail and distribution and transportation and travel companies.

Product Architecture

Figure 1 – OutSystems Agile Platform Architecture (Source OutSystems)

The OutSystems Agile Platform is a visual, code free environment for delivering and managing Web business applications. There are three main product components.

Focus on methods and high power tools


Service Studio The Service Studio is a desktop based, rapid assembly environment for business developers to create and change Web applications using visual models. There is no requirement to write code in order to:

• Build and change Web 2.0 User Interfaces with AJAX integration

• Build and change business logic, database interactions, integration adapters, reusable Web services and maintain security rules

• Deliver and maintain scheduled batch processes

The Service Studio allows consumption and creation of standard Web services using simple, code free tools. In addition it has a reference checking and a self healing engine (TrueChangeTM) that ensures integrity of specifications and models and facilitates change without breaking existing models.

Output from Service Studio is an integrated application definition that is used to generate and deploy the target applications and to track, monitor and automate change.

Developers need basic programming and modeling skills and an understanding of how Web applications work.

Figure 2 – Example Business Logic Definition (Source OutSystems)

Integration Studio The Integration Studio is a desktop environment for developers to create custom components to integrate external applications and databases. These components can then be automatically deployed and become available to be used by Service Studio developers as visual building blocks to create new services and composite applications. Integration Studio includes wizards to identify, map and integrate SQLServer and Oracle database tables, APIs and SAP BAPI components. Custom integration adapters can also be created in conjunction with Microsoft Visual Studio or Eclipse.

Service Center The Service Center is a browser based Web administration console providing general and service specific functions that manage and control everything that happens with the OutSystems Agile Platform administering a collection of services that complement standard .NET or Java applications including:

• Asset management including centralized repository and services repository

• Configuration and versioning

• Security and auditing

• Logging and monitoring

• Performance reports


• Application usage analytics

• Policy management

• Access control

• Manage service resources (scalability)

1-Click Publishing (executed from the Service Studio or Integration Studio) allows immediate testing or execution. TrueChangeTM is a proprietary OutSystems technology that validates dependencies and automates the propagation of that change to its dependencies whenever possible, ensuring no errors remain every time there is a change in an application or component.

Deployed components are run as standard, native .NET or Java code. The Agile Platform allows OutSystems components to be run under the control of OutSystems management services, or if desired, to be detached and run in an entirely native manner.

OutSystems customers report up to 70% reduction in application maintenance costs. Key to this is all application component versions and dependencies are managed in a metadata repository – providing a simplified approach to software configuration management. Application managers can set security policies and monitor application health via the console.

Applications can be changed in minutes or hours with minimal testing.

OutSystems Agile Method

Figure 3 – Eight Stage OutSystems Agile Project (Source OutSystems)

OutSystems recommends its customers adopt a variant of the Scrum Agile method organized in eight stages as shown in Figure 3.

1. Budgeting: Important practices are user stories, sizing and timeboxing.

2. Project Initiation: Bootstrapping the project, assigning roles and responsibilities. Loading stories and features into the Projects component of the Agile Network.

3. Iterative development (Sprints): Development and testing of an agreed Sprint Backlog Settlement using Agile Platform Integration Studio, Service Studio and Service Center. At the end of each Sprint an integrated, working demo is provided to the business users.

4. Training: Passing ownership to the business.


5. Production Launch: Publish application to production using Agile Platform 1-Click publishing technology.

6. Tuning: Refinement of application performance and functionality.

7. Wrap-up: Official close of project

8. Maintenance: Consists of 1 to 2 week Sprints depending on changes and new features required.

Figure 4 – Typical Project Profile (Source OutSystems)

Agile SOA OutSystems recommend their customers adopt an incremental approach to SOA coupled with the Agile practices outlined above. Referring to this as Agile SOA they advise that while a strong corporate wide approach is required within which the incremental activity can be coordinated, early SOA efforts should be focused on specific business process support.

The recommended approach follows the widely used SOA approach in which existing back end systems are wrapped to expose the services needed for specific business process orchestration. The wrapping would be undertaken as a series of narrowly defined sprints focused on specific platform technology or applications. The services are then assembled in a series of solution delivery sprints that create composite applications including process logic and user interfaces. OutSystems comment that in practice they would expect to focus initial sprints on key user stories that identify the services that are required as they are very focused on delivering business value in every sprint. OutSystems provide guidance for this process pattern as follows:

1. Integrate: Create and publish integration adapters using the Integration Studio and new core business services using Service Studio.

2. Assemble: Assemble composite applications using the core business services that consolidate and coordinate data and functionality from potentially multiple sources and introduce caching and synchronization patterns to sustain service levels.


3. Deploy: Automatically deploy using the Agile Platform’s 1-Click Publishing technology.

4. Manage: Using the Service Console, manage and monitor all services from one central location.

5. Change: Ensure ongoing service integrity and governance with True ChangeTM technology.

The Agile Platform is well suited to this process pattern deployed in the early stages of SOA adoption because it is a fully integrated platform environment that eliminates much of the start-up time and cost associated with integrating disparate life cycle delivery and run time infrastructure components. Whilst the OutSystems platform will in the first instance be new to the organization, the start up overheads of familiarization and integration appear to be reasonably low. Similarly skills development needs again appear reasonably low, and the tightly integrated platform environment allows productive delivery to commence almost immediately.

In addition the integrated platform with integrated asset dependency, configuration and change management brings real benefits, cutting what is usually a considerable overhead.

Finally OutSystems provide a portal referred to as the Agile Network, comprising a set of management and training tools that facilitate collaboration between customers and partners involved in agile projects. The tools facilitate:

• Project scoping and sizing – development of a realistic project plan

• Deliver and control – providing project management tools and communication

• Change and evolution – allowing users to submit feedback directly into the application and efficiently communicate needs to project management

Conclusions It seems that most generic Agile method guidance is focused upon best practices. Yet the lessons we learnt and applied in the original RAD method – to focus on methods and high power tools, may have been forgotten. Not so at OutSystems however, who rightly focus equally on the combination of methods and tools to deliver quality and productivity.

In SOA terms OutSystems delivers:

1. Integrated, easy to use tooling which should significantly reduce start up costs and time

2. Rapid delivery of integration adapters to facilitate new core business services

3. Rapid delivery of composite applications

4. A significant reduction in management overhead with comprehensive configuration and asset management.

5. Automated dependency management, reducing cost and time to change, test and redeploy.

OutSystems Agile Platform is likely to be highly effective in delivering composite applications where core business services already exist, or project specific integration is required. Whilst the Agile Platform is clearly effective in creating and integrating services, OutSystems advise that an enterprise perspective is important. In the early stages of a service


portfolio it is important to utilize SOA in areas that demonstrate short term ROI, but a coordination capability will rapidly become a priority.

References OutSystems www.outsystems.com

1 http://en.wikipedia.org/wiki/Scrum_(development)

http://www.outsystems.com/


Product Report: Software AG CentraSite ActiveSOA CentraSite is a SOA governance and lifecycle management product from Software AG. This report looks at how an enterprise user organization may customize and extend the provided capabilities to support the meta model underlying Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports.

By Lawrence Wilkes

Introduction Centrasite ActiveSOA is the new product name for Software AG’s merged portfolio of SOA governance and asset management products. It combines:

• the metadata repository and asset management capabilities of CentraSite Enterprise.

• together with the policy enforcement and governance capabilities of CentraSite Governance Edition. Which itself was a rebranding of the webMethods Infravio X-Registry that Software AG acquired in 2007.

As such, it now provides a comprehensive set of capabilities to support the service lifecycle.

General availability of CentraSite ActiveSOA is scheduled for Q2 of 2009. A Community Edition is also scheduled.

Content Structure and Meta Model It is very difficult to set and enforce policies where the information is unstructured. A well-defined meta model is therefore at the core of enabling SOA governance. Without the appropriate level of precision and granularity in terms of how items are defined and stored in an asset management system it is impossible to apply any rigorous governance in an automated or semi-automated fashion.

ActiveSOA provides a meta model consisting of the following object types.

• Organizations

• Users

• Taxonomies

• Policies

• Assets

• Report Templates

• Lifecycle Models

ActiveSOA ships with a relatively small set of pre-defined Asset Types including the ‘usual suspects’ such as:

• Service (Web Service) and Service Binding

• Interface and Operation Package

• Consumer Application


• Application Server

• Various BPEL assets

• XML schema

Some of these can be seen in the screen capture in Figure 1.

Figure 1 – Some Pre-defined ActiveSOA Asset Types (source: Software AG)

A UI wizard makes it straightforward for users to extend the meta model. Users can define their own custom Asset Types, as well as defining their properties and attributes.

Custom attribute extension of the meta models is typed, which enables for example the use of date pickers and other built-in UI mechanisms for searching assets or applying governance rules. For example, policies can automatically be applied to assets with an attribute of “creation date” that falls between two arbitrary dates.

Associations

Association Types can also be defined to show types of relationships between different Asset Types. Once Association Types have been defined, these can then be referenced in a Relationship Attribute of an Asset Type. For example, the association ‘part of’ is widely used in the CBDI-SAE meta model1. By creating this as an Association Type it can then be added as a Relationship Attribute to ‘Business Type’ (an Asset Type), to show that it is ‘part of’ a ‘Business Domain’ (another Asset Type).

Classifications

Classification Attributes enable an Asset Type to be associated with a taxonomy. For example an organization may wish to classify Services according to CBDI-SAE Service Architecture Layers2.

ActiveSOA only ships with a limited number of taxonomies. These are Asset Type, Organization, and the North American Industry Classification System and Geographical


Location codes, both of which come from UDDI. However, new taxonomies are also straightforward to create via the UI.

Profiles

Profiles can also be defined to create multiple, different ‘views’ of an Asset Type for presentation. For example various default profiles are provided with ActiveSOA that show views such as Summary, Permission, Version, Classification, Association, and Consumer information.

Supporting Documents

ActiveSOA also provides a repository to store additional documents that can be associated with an asset. A File Attribute can be added to an Asset Type to hold a reference to those documents. If the supporting document is held elsewhere however, then a simple URL type attribute can be used to hold its address.

This is most frequently used for documentation, and policies can be established and enforced for ensuring that documentation meets the requirements of the service lifecycle as well.

Extension

It certainly is straightforward to extend the ActiveSOA meta model through the UI. However, the danger is that it may almost be too easy, encouraging users to grow the model in an unplanned way with the risk of a chaotic result. As such, we advise that users should take time to properly model their requirements before commencing any extension activity. The CBDI-SAE Meta Model would of course be a good starting point! Sensibly, the ability to customize the meta model is controlled through permissions, and so granting users Administration permissions that would allow this should therefore be carefully managed.

Using the Asset Catalog

Figure 2 - Graphical View of ActiveSOA Content (source: Software AG)


Access to the Asset Catalog is controlled through a combination of roles such as ‘Asset Provider’ and ‘Asset Consumer’, and permissions such as ‘Create Assets’ and ‘Use Administration UI’.

Using taxonomies and relationships make it easy to browse and search the catalog. Relationships can be viewed graphically, as shown in Figure 2, which also gives an indication of the number of instances in a relationship. As well as improving the understanding of relationships between assets, this is useful when performing impact analysis.

Users can limit browsing and searching by classification for example, and they can also save searches so that they can be used by others. This is useful in the graphical view as dependencies can become exceedingly complex, and saved searches are essentially a way of “slicing” the dependency “space” visually.

Users can also set up event notifications to inform them when objects are read, created, updated or deleted.

Assets can be created from scratch or updated through the UI, or many cases might be imported from some external source, such as Web Services from a UDDI registry. This is further discussed later in the report.

Service Lifecycle and Governance ActiveSOA provides a state machine to define lifecycles that can be applied to various objects including Asset Types, Organizations, Taxonomies, policies and lifecycle models themselves. Policies can then be applied to state changes and other events to support the governance process.

ActiveSOA allows multiple lifecycles to be defined and applied to different objects. It also allows for both ‘system-wide’ and ‘organization specific’ lifecycles, so that Asset Types for example that are owned by an organization unit can be subject to a lifecycle that is also owned by, and specific to that unit.

Users with appropriate permissions can extend and define their own lifecycle models through the UI, defining the states and transitions, the object it applies to, as shown in Figure 3.

Policies are executed on events, such as state transitions defined in a lifecycle model, or pre and post events when an object is read, created, changed or deleted. These dynamic event triggers are key to establishing complex workflows during the change time governance of highly interdependent asset types.

Policies can be set to validate the values of attributes or the existence of relationships. This can be used to enforce the constraints that may be inherent in the meta model and delivery approach that the organization is following. For example, using the CBDI-SAE meta model you would ensure that a Business Service is associated with a Business Service Subject, and that a Service Specification is assigned to an appropriate Architecture Layer.

ActiveSOA provides a set of predefined design/change time ‘Action Templates’ that form building blocks that be used to define a policy, some examples of which are shown in Figure 4. Not only can these validate attribute values, but can also set them. They can also initiate workflows such as approvals, and presume everything is approved and OK, can then set the appropriate lifecycle state.


Figure 3 – Defining the Lifecycle Model in ActiveSOA (source: Software AG)

Figure 4 - Action Templates (source: Software AG)


As their name suggests, pre-defined WS-I compliance actions can test for compliance with certain Web Service protocol interoperability profiles from the WS-I organization3

Policies are straightforward to author via the UI, as illustrated in Figure 5. Relevant objects and events are selected, and then appropriate actions can be defined.

Figure 5 - Authoring Policies with ActiveSOA (source: Software AG)

Users can also develop their own custom Action Templates. ActiveSOA supports both:

• manual actions where user interaction is required, such as an Approval process.

• programmatic actions that trigger action rules, typically coded as Java classes.

Using the API’s described later, it is also possible to apply the lifecycle management capabilities of ActiveSOA to assets stored externally.

Policy Management As well as design/change time policies, certain run-time policies can also be authored and managed in ActiveSOA, and then pushed out to an appropriate ‘policy enforcement point’ (PEP) in a run-time engine. ActiveSOA ships with built-in Action Templates for:

• Security

• Performance Monitoring

• Event Logging

• Message Validation

However, these are designed specifically to use Software AG’s webMethods Mediator product as the PEP, which is designed to be configured using ActiveSOA.


In addition, many of the popular run-time PEPs in alternative products have been pre-integrated through the Centrasite Community. Integrations typically go beyond just pushing runtime policy into runtime PEPs and often also provide for runtime metrics to flow back into Centrasite ActiveSOA in order for users of the Registry Repository to understand runtime behavior of services before binding.

Users also have the ability to author their own custom actions if support for the PEP they are targeting is not already available.

The run-time policies are negotiated as contracts - unique statements of the run-time policy requirements between provider and consumer. Although the contracts are enforced by the PEP in the run-time system, they must also be negotiated by the service consumer with ActiveSOA when they decide to use the Service. This is a very useful facet of the full lifecycle capabilities of ActiveSOA.

Versioning and Configurations ActiveSOA provides for major or minor versioning of objects. A major version creates a new ‘cloned’ object with its own unique id, whereas a minor version is just an update of the existing object. It is also possible to create associations between major versions of objects – as they are each just unique objects - which may be useful when multiple versions of a Web Service for example are all still operational.

There is no specific mechanism to define ‘configurations’ of Asset Types or other objects, along the lines of those discussed in previous reports, such as a Service Portfolio Plan consisting of various architecture models, a list of Services, Service Specifications and so forth. However, it would be straightforward to define Service Portfolio Plan as a new Asset Type together with the required Association Types and relationship attributes needed. It could also link to any supporting documents, or objects held elsewhere as discussed earlier. Policies could then check the completeness of the plan and associated assets as the plan moves through its lifecycle.

Interoperability Most activities that can be performed via the UI can also be performed via one of the APIs provided as part of the SOALink framework, some of which are summarized in Table 1.

The SOALink Cookbook4 describes a number of design and run-time integration scenarios, and provides guidance and some already developed APIs to integrate with other products, or use their agents.

Using the registry API, ActiveSOA can be deployed as a federated registry consisting of both ActiveSOA and other UDDI registries, providing automatic and manual synchronization. Custom plugins into the federation framework also allow for federation with arbitrary non UDDI compliant systems.

ActiveSOA can also act as a ‘system of record’ by providing a centralized information store into which other design and run-time tools can publish relevant information or events. For example, development tools, configuration management tools, or other registries might publish asset dependencies into ActiveSOA. Whilst systems management tools or an Enterprise Service Bus might publish metrics or run-time events to ActiveSOA.


IDE and other development tools

Eclipse plug in – can use Eclipse Registry Browser

Has own interfaces into some 3rd party systems

Partners or users can develop own custom imports, using guidance found in SOA Link

UDDI Registry Can interface to other UDDI-compliant registries using

• UDDI 3.0 Registry access

• JAXR (Java API for Registries) supporting both UDDI 2.0 and ebXML 2.0 registries

CMDB No specific integration to a CMDB is provided, but using the APIs, it is possible to link between objects in a CMDB and assets in ActiveSOA providing the type of object is common to both.

Other APIs • Lifecycle Management API provides Javadoc access to lifecycle models. It is possible to apply lifecycle management to external assets, not just those in the ActiveSOA repository.

• CentraSite Application Framework (CSAF) provides a programming model for developing custom extensions on top of CentraSite.

• Java Management Interface

Table 1 - Interoperability Features of ActiveSOA

Representing CBDI-SAE There are no specific considerations for defining types from the CBDI-SAE meta model or SAE deliverables. As Table 2 shows, most would be defined as Asset Types together with appropriate relationship attributes to other relevant Asset Types.

As such it would be fairly straightforward to use ActiveSOA to support a CBDI-SAE approach.

SAE Deliverable or Concept

Instantiation in Active SOA

Service (notional) Asset Type. Relationship Attributes to other asset types such as,

• One or more Service Specifications

Service Portfolio Asset Type. Relationship Attributes to other relevant Asset Types that would be found in the portfolio plan, such as

• Business Models (URL pointer to)

• Service Architectures

• Service (notional)


Service Architecture Asset Type. Relationship Attributes to Service Specifications

URL Attributes to point to Architecture Model , or File Attributes if the model is held in the repository as a supporting document

Service Specification Asset Type. Relationship to other asset types such as,

• Specified Operation

URL Attributes to point to Service Information Model, or File Attributes if the model is held in the repository as a supporting document

Specified Operation Asset Type. This would be added as a new asset type rather than customizing the provided Operation asset type, which would be left as is to represent Java operations

Relationship Attribute to XML Schema

Service Level Agreement Asset Type.

Run-time SLAs can be defined in ActiveSOA that run in Mediator.

Automation Unit Specification

Asset Type. File Attributes or URL links to associated models and other objects used in implementation

Policy Type ActiveSOA doesn’t support the concept of a Policy Type, but you can develop custom action templates that can be reused when defining policies

Policy Policies

Table 2 - Defining CBDI-SAE in ActiveSOA

Summary Centrasite ActiveSOA represents an amalgamation of mature products that together have over 200 customers.

ActiveSOA is a straightforward product to use and customize via its UI. At the same time, a complete set of APIs enable it to be integrated with other products to support the SOA delivery and operational lifecycles, and there is an active community of users and partners developing 3rd party support.

Out of the box, ActiveSOA does not provide a particularly rich set of pre-defined asset types, and is focused on implementation and run-time assets, but this is no different to similar products. However, the list of asset types is easily extended. Similarly it is easy to create other objects such as taxonomies, lifecycle models and policies.

We can imagine that organizations would be ‘up and running’ quickly with ActiveSOA. However, as mentioned earlier we still recommend that they carefully plan their extensions to the meta model, as well as deciding roles and access control models first.


Links Centrasite http://www.softwareag.com/corporate/products/wm/soa_governance/default.asp

Centrasite Community for plug-ins http://communities.softwareag.com/ecosystem/communities/public/developer/centrasite/

1 CBDI-SAE Meta Model V2.0. http://www.cbdiforum.com/public/CBDI_SAE_META_MODEL_FOR_SOA_V2.0.pdf 2 See Appendix A1. Architecture Layers, in CBDI-SAE Meta Model V2.0. 3 http://www.ws-i.org/deliverables/Default.aspx 4 SOALink Cookbook. http://documentation.softwareag.com/webmethods/soal8/overview.htm

http://www.softwareag.com/corporate/products/wm/soa_governance/default.asp

http://communities.softwareag.com/ecosystem/communities/public/developer/centrasite/


About CBDI CBDI Forum is the Everware-CBDI research capability and portal providing independent guidance on best practice in service oriented architecture and related disciplines.

Working with F5000 enterprises and governments the CBDI Research Team is progressively developing structured methodology and reference architecture for all aspects of SOA.

CBDI Products A CBDI Forum subscription provides an enterprise or individual with access to a unique knowledgebase, ongoing practice research , guidance materials and resources.

The CBDI Journal, published 11 times a year provides in-depth treatment of key practice issues for all roles and disciplines involved in planning, architecting, managing and delivering business solutions.

Platinum subscription – access to all CBDI research and knowledge products including the SAE Knowledgebase

Gold subscription -access to the CBDI Journal past and present, plus other premium reports and foundational eLearning materials

Consulting Services - always highly focused, either short sharp initiatives designed to accelerate the customer’s current capability, or longer term mentoring relationships. In both cases our services are provided by expert practitioners whose objectives are to effect skills transfer.

Education Services – face to face and eLearning products. Options include train the trainer and customization.

Contact CBDI For further information on CBDI products and services contact [email protected]

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognized and acknowledged.

mailto:[email protected]