Movie: Tutorial 1 - Business Analysis Iteration 1

I have produced a movie, which will be the first of a set of mini tutorials, to demonstrate both the SAVARA methodology and tooling.

The first tutorial can be found at: http://downloads.jboss.org/savara/tutorials/Tutorial_1_BusinessAnalysis_Iteration_1

This tutorial covers the following:

• Defining the participants and relationships between them
• Creating a scenario to represent a business requirement
• Creating example messages for use with the scenarios
• Specifying the initial architectural model defined using a Choreography Description
• Verifying that the architectural model meets the business requirements
  

DZone Q&A on SAVARA

There is a Q&A session on SAVARA at: http://www.dzone.com/links/qa_creating_testable_architectures_with_savara.html

Unfortunately there are some transcription errors - so may be best to listen to the podcast of the actual interview :)

SAVARA 1.0 Milestone 1 Released

We are pleased to announce the first milestone release for SAVARA 1.0.

More details about the release can be found at: http://community.jboss.org/thread/146018?tstart=0

Alignment of SAVARA (Testable Architecture) to TOGAF

The importance of SAVARA becoming a standard method / toolset for enterprise and solution architects to clearly  and formally describe system (collaboration / communication) architectures cannot be emphasised enough. The benefits seen in early implementations of Testable architectures (the underpinnings of SAVARA) have been impressive to say the least.

In the same light, there is an increased acceptance of enterprise architecture framework like TOGAF in the industry which enables clear architecture descriptions, reduces redundancies and improves architecture output and adds value to the business solution.

Please see the downloadable whitepaper below which brings these two methodologies together and specifies the broad alignment of SAVARA (Testable Architecture) to The Open Group Enterprise Architecture Framework (TOGAF) showcasing that SAVARA can be used in conjunction with accepted enterprise modelling languages like Archimate to describe communications architecture  in formal and testable manner using simulation and visualisation.



http://docs.jboss.org/savara/whitepapers/Testable_Architecture_and_TOGAF.pdf

SAVARA and the SOA Manifesto

A group of leading SOA evangelists recently met in Rotterdam to agree an "SOA Manifesto". This work resulted in a list of guiding principles that have been documented here.

Initial feedback has been positive, although one common theme through many comments has been the lack of detail. However it provides a similar level of detail as the popular Agile Manifesto, and therefore I don't see this as a major issue at this stage.

The main purpose of this meeting was to establish the high level principles. I think it is how these principles are subsequently applied that will determine the success of this manifesto.

There are a number of ways in which the SAVARA project can help support these guiding principles:

"SOA can be realized through a variety of technologies and standards."

One of the goals of SAVARA is to provide a methodology and tool framework that can accommodate various technologies and standards, in a way that can deliver a testable architecture where the different artifacts can be validated against each other.

"Identify services through collaboration with business and technology stakeholders."

The SAVARA methodology covers the complete development lifecycle, helping to capture the requirements from the business and technology stakeholders, through defining the architecture, to service identification/analysis, design, implementation and deployment.

"Verify that services satisfy business requirements and goals."

This is the main aim of a testable architecture, to ensure that the artifacts at each stage of the development lifecycle are valid compared to artifacts from preceding stages, thus ensuring that the deployed services can be shown to indirectly satisfy the original business requirements.

"Evolve services and their organization in response to real use."

Through a detailed understanding of the behaviour of a system, from requirements through to implementation, it makes it easier to accommodate changes in requirements and understand the impact of the changes on a production environment. This manageability is critical to enable a system to evolve as efficiently as possible without introducing risk to the business.

"Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change."

SAVARA enables the behavioural dependencies to be understood, thus significantly reducing the potential impact of change.

TOGAF meets Savara

Last time I blogged about Togaf I said “TOGAF gives you some generic artefacts. But it is up to you to gather and decide which artefacts you need. How do you decide "what you need?" How do you know that "what you need" is "what it takes?”

Let’s focus on one single artefact: requirements.

Some of Togaf prescribed requirements are inputs or outputs to the following phases:

• Preliminary Phase: Stakeholder’s requirements
• Requirements Management: Requirements-related inputs/outputs from each Togaf ADM phase
• Phase Architecture Vision: Business requirements, Stakeholder’s requirements
• Business Architecture: Technical requirements, Business requirements
• Information Systems Architectures – Data Architecture: Architecture Requirements, Data interoperability requirements, Technical requirements, Business requirements, Application requirements
• Information Systems Architectures – Application Architecture: Application interoperability requirements, Technical requirements, Business requirements, Updated data requirements
• Technology Architecture: Technical requirements
• Opportunities & Solutions: Draft Architecture requirements, Interoperability and co-existence requirements
• Migration Planning: Finalized Architecture requirements specification
• Implementation Governance: Recommendations on service delivery requirements

From this large set of requirements, a subset will be used as input by solution architectures. The question that I want to pose is “how do we ensure that all artefacts created throughout the lifecycle of a software development project are verifiable against these requirements?” or more specifically “how do we know that the solution architectures we create actually meet the requirements that they are based upon?”.

Savara is your answer. Using Savara it is is possible to ensure that the delivered system conforms to the original set of requirements.

Integrating Togaf ADM and Savara puts you in the position of ensuring that the delivered systems conform to the original set of requirements.

The underpinings of this can be found in Steve’s blog where he talks about successive refinement of req uirements and models. In my next blog I want to revist this and align it more explicitly to TOGAF.

In my next blog I want to revist this and align it more explicitly to TOGAF.

More on the SOA-Manifesto

I have been thinking ever more about the SOA Manifesto. In part fuelled by the proximity of the WG meeting and in part by comments that have been made.

I take on board the comments on the need for "boldness" I have never been shy about dealing with that. But we need to ensure that the manifesto has use today that is practical and very business focused - something I have picked up from the many comments made at infoQ. And we need to map out what is missing and look deeper into a brave new world that builds upon our current available SOA platforms and methods of constructing solutions.

One thing stands out for me on the practical usage side and one on the future.

On the practical side:

• The use of Service Orientation is underpinned by delivering continuous business value. Business value MUST always be aligned to business goals and needs.

In the future:

• It MUST be possible to express the information model(s), the static service model and the dynamic model of service collaboration such that the first describes the data needs of services, the second describes the service usage across peers of a specific service and the third describes the common collaborative behavior of peers collectively. All of which MUST be founded upon one or more business requirements.

I think these two and refinements of them will stand us in good stead. The devil is always in the detail.

The former is really motherhood and apple pie. Easy to say but how do we bake it?

The latter is more of challenge because it requires a better understanding of what underpins a distributed system in terms of behavior and information that drives that behavior and these, at the end of the day, are complex mathematical topics. We must be careful and ensure that we do not go into too much detail but provide the right syntactic sugar that allows formalism to deliver to us in a way that we can all understand and use.

Let us not forget that without mathematics we would have no computing. In fact without it we would have no engineering. They are all based on mathematics but we rarely see the models that are used to underpin engineering but in the case of computing we use those models all the time. They have syntactic sugar we call them programming languages.

A Personal Architecture Manifesto (cross blogged)

Way back in 2004 a good friend of mine, Alexis Richardson, decided to convene a summit of architects. The summary of the event is below:

The Architects Summit is a one off event challenging a group of pragmatic and active technologists to formulate, document and publish a consensus view on requirements and best practice for software application platforms and development tools.

I cannot remember now how many turned up but it was well attended and amongst the participant Chris Swan and Hugh Grant were there, Rod Johnson was there, Matthew Rawlings, John Davies, Cameron Purdy and many others.

I was asked to co-chair with Alexis, presumably because chairing seems to be my thing amongst a diverse set of individuals and opinion.

The net result was certainly a stimulating debate but no manifesto was ever issued because we could not get agreement. In part this was because the camps divided into classic enterprise architects and guru-status technical architects. And never the twain can agree.

However, given the fashion for manifesto’s here is my own personal one which was done at that time and to which I still pretty well subscribe to.

Outline structure for Testable Architecture Methodology now on the wiki

An outline structure for the Testable Architecture Methodology has been uploaded to the wiki. This outline is intended to help refine the phases, and steps within those phases, before the methodology is encoded using Eclipse Process Framework.

For more information please see: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257011#4257011 and http://www.jboss.org/community/wiki/TestableArchitectureMethodology

In the press

SAVARA project officially launched at JBossWorld, and on the Red Hat press blog.

Announcing the SAVARA project

 We are pleased to announce a new jboss community project, called Savara, established in collaboration with Cognizant (www.cognizant.com ) and Amentra (www.amentra.com ).

The purpose of this project is to develop a new methodology for Enterprise Architecture and Distributed Computing, called “Testable Architecture”, and provide appropriate tooling support.

This methodology aims to ensure that any artifacts defined during the development lifecycle can be validated against other artifacts in preceding and subsequent phases. This ensures that the final delivered system is guaranteed to meet the original business requirements. Through runtime governance, it is also possible to ensure that the running system continues to meet those requirements.

As a system evolves, through subsequent enhancements to the business requirements, having such a precise understanding of the system, from requirements, through design, implementation and deployment, enables more sophisticated change management techniques to be considered.

For more information on the project, please visit the project website.