Tuesday, 27 October 2009
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.
Friday, 16 October 2009
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
In my next blog I want to revist this and align it more explicitly to TOGAF.
Thursday, 15 October 2009
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.
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.
Wednesday, 7 October 2009
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.