I was watching and listening to Dan North and Michael Feathers on the web. It is worth a look. At about 12 minutes Dan says the following "You can TBD your way out of anything... There is balance between doing all up front design and doing no up front anything which is irresponsible." and he mentions that Richard Watt says "Enough up-front thinking" is what you need.
The tension between agile and "enough up front thinking" is what I want to explore. Those agile bigots that think you should not do anything up front miss the point. Hopefully there are not too many of them. Having deployed "testable architecture" in several sites now I do get asked how does this work with agile. And I think Dan and Michael have really nailed it.
What is enough?
The communication/interaction model between services in an SOA is probably a good place to start. The aim is to provide enough structure without getting in the face of developers who will operate in an agile process. If testable architecture, embodied today in the pi4soa tools, provides the necessary communication/interaction model along with the necessary minimum data structures (for example the business transaction identities needed to support the communication model and any asserted state thereafter) then we can (and we have in Cognizant) use it to provide "what is enough" and thereafter engage developers in an agile process to fill in the gaps. The structure is preserved and testable against requirements, as I have often said in my other posts. And in more recent posts that structure remains a valuable testable artefact for systems integration testing.
Saturday, 4 July 2009
Thursday, 18 June 2009
Defect Detection in Systems Integration Testing
Another short movie to illustrate a point. This time I want to move to the left brain side of the testable architecture methodology and deal with the issues that confront many of us on complex programmes.
The issue is one of defect detection, and I want to specifically highlight how we can use testable architecture in its current form (aka WS-CDL and the pi4soa tool-suite) to detect a system defect. The defect is categorised by a variation in the system wide (and so end-point specific) contract for the services. In this case we change the contract and update one of the services but not the other. It is a pretty typical problem that is hard to identify (although not impossible) during systems integration testing. What we do here is use the monitoring capabilities during the system integration testing to determine the root cause of the problem.
It is only but a short jump from here to full run time governance. And that is what Overlord is all about.
Enjoy.
The issue is one of defect detection, and I want to specifically highlight how we can use testable architecture in its current form (aka WS-CDL and the pi4soa tool-suite) to detect a system defect. The defect is categorised by a variation in the system wide (and so end-point specific) contract for the services. In this case we change the contract and update one of the services but not the other. It is a pretty typical problem that is hard to identify (although not impossible) during systems integration testing. What we do here is use the monitoring capabilities during the system integration testing to determine the root cause of the problem.
It is only but a short jump from here to full run time governance. And that is what Overlord is all about.
Enjoy.
Thursday, 28 May 2009
Global Models
Perhaps the biggest contribution that the Choreography Working Group has made, along with our academic colleagues and colleagues from many vertical standards organisations, is the formulation of a global model. WS-CDL was the first attempt at codifying such a model.
BPMN2 when it is finally released will have done us a huge service if, as we expect, it combines both global and local behaviors. The lack of a local model for behavior has long been a gap in our thinking on global models and would add the refinement needed to go from very high level to executable artefacts in a controlled and refined way.
So it was great to see the blog at Overlord that welcomes BPMN2 to the world.
BPMN2 when it is finally released will have done us a huge service if, as we expect, it combines both global and local behaviors. The lack of a local model for behavior has long been a gap in our thinking on global models and would add the refinement needed to go from very high level to executable artefacts in a controlled and refined way.
So it was great to see the blog at Overlord that welcomes BPMN2 to the world.
Wednesday, 22 April 2009
Sunday, 15 February 2009
Using formal methods to support an offshore global delivery method
I have blogged before on this topic but now I want to share some of the results with you.
I was recently involved in two insurance focused system integration initiatives. The fact that they were in insurance is more suggestive that the same approach can work anywhere as insurance tends to be fairly conservative when it comes to new technology.
The background, in both cases, was an in-flight SOA-road map that was being executed. The road map required integration of legacy applications and portal development to support a user experience. A classic ESB approach was used to manage integration and provide both mapping from and to a legacy message format and mediate between the new functionality and the old legacy system. For the most part this is straight forward, or at least so it seems. Estimates were given for the two initiatives to provide the necessary technical contract that would drive implementation offshore.
In the first instance the allotted time to develop a solution and provide the technical contracts was of the order of 15 days effort. This would involve gathering requirements, functional and non-functional, looking at message formats to support the data model, understanding the business transactions so that the solution could be effectively monitored, delivering service contracts for the mapper and mediator services, providing state diagrams to show the individual service behaviors needed and sequence diagrams to provide a collaboration context. The total number of services was 4 including the client, the mediator, mapper and legacy service.
In the second instance the allotted time to develop a solution was of the order of 60 days of effort. In this case there were many more services (I prefer to call them roles) that needed to be understood and many more interactions between those roles. The same level of technical contracts was required to be delivered over the 8 or so roles.
In both cases we used testable architecture. We gathered the requirements initially framed as use cases in UML like notation and then used the pi4soa collaboration tool suite to create sequence diagrams (in which each link referred to an example message in the scenario being modeled) to support each of the use cases. These were then used to drive the development of a CDL model and that model was tested against the sequence diagrams. This represents the left part of the method shown below:
In the first case it tool less than one day to gather the requirements and deliver the tested model. In the second case it took 4 days to do the same. The technical contracts, the WSDL, the BPEL, the BPMN, the state diagrams, sequence diagrams and much more took a few clicks as they were generated from the CDL model.
It may sound fantastical and mythical that we compressed the effort by some 80%. But the fact is that we did. Not only that we found design flaws early both in our use of BPEL and WSDL. We found competing requirements and corrected them and we produced technical contracts that were far more rigourous and complete and unambiguous than we had managed to achieve by hand.
In the early development of the pi4soa toosuite we developed a full FpML model of derivatives trading from indication of interest through to the end of economic life of a derivative. I don't claim that this model was correct but the process of doing it took 4 weeks to complete and in the process a far greater understanding of derivatives processing was gained by both those doing the model and those providing the expertese of derivative processing. Similarly with TWIST and payments and more recently with HL7.
Some question the value of descriptions. All I can say is that the proof is fairly evident that describing something well has the effect that one better understands what is required and design flaws tend to be highlighted. In the insurance enagagements and the much larger FpML engagement the use of testable architecture, the gathering of requirements as sequence diagrams with messages, the modeling of the entire set of requirements and the formal testing of the model against those requirements and finally the generation of technical contracts is without peer. I know of nothing similar that can do this.
Fortunately I work, these days, for a large systems integrator (Cognizant Technology Solutions). This has given me the chance of trying this stuff out and showing I have always believed to be true which is simply that the impact of description through a formal method will help to change the way in which we can effectively do more for less with higher quality and so move the entire process of creating solutions up one level of abstraction with no loss in our ability to express a solution.
I was recently involved in two insurance focused system integration initiatives. The fact that they were in insurance is more suggestive that the same approach can work anywhere as insurance tends to be fairly conservative when it comes to new technology.
The background, in both cases, was an in-flight SOA-road map that was being executed. The road map required integration of legacy applications and portal development to support a user experience. A classic ESB approach was used to manage integration and provide both mapping from and to a legacy message format and mediate between the new functionality and the old legacy system. For the most part this is straight forward, or at least so it seems. Estimates were given for the two initiatives to provide the necessary technical contract that would drive implementation offshore.
In the first instance the allotted time to develop a solution and provide the technical contracts was of the order of 15 days effort. This would involve gathering requirements, functional and non-functional, looking at message formats to support the data model, understanding the business transactions so that the solution could be effectively monitored, delivering service contracts for the mapper and mediator services, providing state diagrams to show the individual service behaviors needed and sequence diagrams to provide a collaboration context. The total number of services was 4 including the client, the mediator, mapper and legacy service.
In the second instance the allotted time to develop a solution was of the order of 60 days of effort. In this case there were many more services (I prefer to call them roles) that needed to be understood and many more interactions between those roles. The same level of technical contracts was required to be delivered over the 8 or so roles.
In both cases we used testable architecture. We gathered the requirements initially framed as use cases in UML like notation and then used the pi4soa collaboration tool suite to create sequence diagrams (in which each link referred to an example message in the scenario being modeled) to support each of the use cases. These were then used to drive the development of a CDL model and that model was tested against the sequence diagrams. This represents the left part of the method shown below:
In the first case it tool less than one day to gather the requirements and deliver the tested model. In the second case it took 4 days to do the same. The technical contracts, the WSDL, the BPEL, the BPMN, the state diagrams, sequence diagrams and much more took a few clicks as they were generated from the CDL model.
It may sound fantastical and mythical that we compressed the effort by some 80%. But the fact is that we did. Not only that we found design flaws early both in our use of BPEL and WSDL. We found competing requirements and corrected them and we produced technical contracts that were far more rigourous and complete and unambiguous than we had managed to achieve by hand.
In the early development of the pi4soa toosuite we developed a full FpML model of derivatives trading from indication of interest through to the end of economic life of a derivative. I don't claim that this model was correct but the process of doing it took 4 weeks to complete and in the process a far greater understanding of derivatives processing was gained by both those doing the model and those providing the expertese of derivative processing. Similarly with TWIST and payments and more recently with HL7.
Some question the value of descriptions. All I can say is that the proof is fairly evident that describing something well has the effect that one better understands what is required and design flaws tend to be highlighted. In the insurance enagagements and the much larger FpML engagement the use of testable architecture, the gathering of requirements as sequence diagrams with messages, the modeling of the entire set of requirements and the formal testing of the model against those requirements and finally the generation of technical contracts is without peer. I know of nothing similar that can do this.
Fortunately I work, these days, for a large systems integrator (Cognizant Technology Solutions). This has given me the chance of trying this stuff out and showing I have always believed to be true which is simply that the impact of description through a formal method will help to change the way in which we can effectively do more for less with higher quality and so move the entire process of creating solutions up one level of abstraction with no loss in our ability to express a solution.
Friday, 12 December 2008
Offshoring and Specification - Improving the Global Delivery Model
Offshoring has been something with us for at least 10 years. Initially much of it was targeted at testing. There has been a lot written about offshoring and on the role specification plays in achieving a successful offshoring delivery model. So it is to this relationship between an engine that has a global delivery capability (and Cognizant is a fine example of this) and how to make it even better that I blog.
Offshoring is often done on fixed price terms. The financial size of the project and the way in which the contract and subsequent remuneration is managed relies heavily on specifications, governance of the delivery and change management. To date most offshoring companies have similar, although with subtle differences, models for doing this.
The advent of UML as a language for modeling and specifications has certainly helped in understanding what should be delivered. The use of programme management and enterprise architecture functions to govern delivery with clients is a common feature. Many offshoring companies and indeed those that were local Systems Integrators have to a large extent pioneered the roles that we play; from the programme management roles to the enterprise architect roles. Governance and supporting frameworks have been developed to help the process and have been used to great effect. TOGAF certified architects, MSP certified programme managers are in demand. Of course this does not mean TOGAF and MSP are the only games in town, I only mention them because they are well known.
The fundamental cost in offshoring the Software Development Life Cycle (SDLC) is one of people. And because people are involved the removal of ambiguity in specifications where possible is a critical success factor it both protecting the margins of offshoring companies as well as protecting the delivery of solutions to customers.
Not much has changes in terms of the specifications and the methods to create specifications nor in the way in which specification are used to guide the SDLC. Typically success is characterised by a model in which an Enterprise Architect may work alongside Business Analysts onshore to frame a solution and the Programme Manager liaises with the customer and Enterprise Architect to ensure a suitable roadmap for phased delivery of the solution. The same two roles work together on the contract details which reflect the roadmap. The programme (that is the collection of projects needed to deliver the solution) kicks off and the Enterprise Architect and Programme Manager (often with similar roles from the client) ensure the programme is well governed meeting all the targets and adhering to the standards of communication and delivery needed as well as managing changes.
Within the process that is enacted the specification of the solution becomes a key part for both governance and change management. The specification is the document (or documents) that detail what needs to be built in order to deliver the solution. Of course the entire process is larger than just this piece but for the most part the rest of the process deals with change management and seeks to ensure alignment of the solution to the customers needs throughout the life of the programme - hence change management because what we think is correct never is what is needed over the life of a programme; things change.
The specifications delivered to an offshore engine need to make clear what functions need to be written, what inputs they might have and what outputs they might deliver. The specification needs to make clear the order that functions can be used. I have not mentioned data explicitly because it has no meaning without the functions. A piece of data is just that until we decide to do something with it. What we do with it is essentially a function.
The challenge to creating and delivering good specifications is to ensure that they are internally consistent, that they are externally complementary - by which we mean that two pieces of software will work together or interoperate, that they are aligned to the business goals of the customer.
The way in which we meet the first challenge - internally consistent - is largely through governance and within it review. They way we meet the second challenge is the same. The way we meet the third challenge is through transparency with the customer of the SDLC and the solutioning process and of course through continued governance.
Of course when things change we need to assess the impact of that change to projects already in flight. Again this is done through review under governance.
The pattern here is that the key challenges are met with people based processes. And the problem with that is that it is ambiguous. The specification are often ambiguous internally and even more so externally. Not because people are not trying by because the level of abstraction for specifications is not amenable to adequately describe what is needed.
If we use UML State Machines and WSDL contracts as an example. We might have 100 services to create. They all have WSDL contracts. Some of the services will be stateless (typically data look ups, technical services and so on), some will be stateful (this doesn't mean they hold state within the interface but it may well mean that they have knowledge of one or more business transactions and so state relative to the business transaction becomes very important). If 20 of these services need to collaborate then the UML State Machines need to reflect that collaboration. The way we ensure it works is to check each State Machine against what we think are the related State Machines. As an example look at the two below, they should be complementary but are they?
Life got a little better when BPMN came along. It's level of abstraction is higher. But the problem with this is that it very quickly becomes unmangeable and unintelligable because the complexity is delivered as links across services (the roles or actors). Imagine a BPMN diagram for a seemingly straight forward problem. I show one below and you see immediately that the complexity makes it unreadable (and yes I know it is small but the point is that the picture is clearly complex).
So how do we do it better? How can we deliver better specifications and so improve the global delivery model and leverage offshoring at an industrial scale without needed so many heavy people based processes? In short how can we automate some of this and use computational power to make our lives easier?
The answer is to use testable architecture. In my next blog I shall show how it works and how it can be applied and the benefits that ensue. I shall leave you now with a simple business view of testable architecture for a simple example that was generated from a language that is unambiguous and really does specify at the right level of abstraction:
Offshoring is often done on fixed price terms. The financial size of the project and the way in which the contract and subsequent remuneration is managed relies heavily on specifications, governance of the delivery and change management. To date most offshoring companies have similar, although with subtle differences, models for doing this.
The advent of UML as a language for modeling and specifications has certainly helped in understanding what should be delivered. The use of programme management and enterprise architecture functions to govern delivery with clients is a common feature. Many offshoring companies and indeed those that were local Systems Integrators have to a large extent pioneered the roles that we play; from the programme management roles to the enterprise architect roles. Governance and supporting frameworks have been developed to help the process and have been used to great effect. TOGAF certified architects, MSP certified programme managers are in demand. Of course this does not mean TOGAF and MSP are the only games in town, I only mention them because they are well known.
The fundamental cost in offshoring the Software Development Life Cycle (SDLC) is one of people. And because people are involved the removal of ambiguity in specifications where possible is a critical success factor it both protecting the margins of offshoring companies as well as protecting the delivery of solutions to customers.
Not much has changes in terms of the specifications and the methods to create specifications nor in the way in which specification are used to guide the SDLC. Typically success is characterised by a model in which an Enterprise Architect may work alongside Business Analysts onshore to frame a solution and the Programme Manager liaises with the customer and Enterprise Architect to ensure a suitable roadmap for phased delivery of the solution. The same two roles work together on the contract details which reflect the roadmap. The programme (that is the collection of projects needed to deliver the solution) kicks off and the Enterprise Architect and Programme Manager (often with similar roles from the client) ensure the programme is well governed meeting all the targets and adhering to the standards of communication and delivery needed as well as managing changes.
Within the process that is enacted the specification of the solution becomes a key part for both governance and change management. The specification is the document (or documents) that detail what needs to be built in order to deliver the solution. Of course the entire process is larger than just this piece but for the most part the rest of the process deals with change management and seeks to ensure alignment of the solution to the customers needs throughout the life of the programme - hence change management because what we think is correct never is what is needed over the life of a programme; things change.
The specifications delivered to an offshore engine need to make clear what functions need to be written, what inputs they might have and what outputs they might deliver. The specification needs to make clear the order that functions can be used. I have not mentioned data explicitly because it has no meaning without the functions. A piece of data is just that until we decide to do something with it. What we do with it is essentially a function.
The challenge to creating and delivering good specifications is to ensure that they are internally consistent, that they are externally complementary - by which we mean that two pieces of software will work together or interoperate, that they are aligned to the business goals of the customer.
The way in which we meet the first challenge - internally consistent - is largely through governance and within it review. They way we meet the second challenge is the same. The way we meet the third challenge is through transparency with the customer of the SDLC and the solutioning process and of course through continued governance.
Of course when things change we need to assess the impact of that change to projects already in flight. Again this is done through review under governance.
The pattern here is that the key challenges are met with people based processes. And the problem with that is that it is ambiguous. The specification are often ambiguous internally and even more so externally. Not because people are not trying by because the level of abstraction for specifications is not amenable to adequately describe what is needed.
If we use UML State Machines and WSDL contracts as an example. We might have 100 services to create. They all have WSDL contracts. Some of the services will be stateless (typically data look ups, technical services and so on), some will be stateful (this doesn't mean they hold state within the interface but it may well mean that they have knowledge of one or more business transactions and so state relative to the business transaction becomes very important). If 20 of these services need to collaborate then the UML State Machines need to reflect that collaboration. The way we ensure it works is to check each State Machine against what we think are the related State Machines. As an example look at the two below, they should be complementary but are they?
Life got a little better when BPMN came along. It's level of abstraction is higher. But the problem with this is that it very quickly becomes unmangeable and unintelligable because the complexity is delivered as links across services (the roles or actors). Imagine a BPMN diagram for a seemingly straight forward problem. I show one below and you see immediately that the complexity makes it unreadable (and yes I know it is small but the point is that the picture is clearly complex).
So how do we do it better? How can we deliver better specifications and so improve the global delivery model and leverage offshoring at an industrial scale without needed so many heavy people based processes? In short how can we automate some of this and use computational power to make our lives easier?
The answer is to use testable architecture. In my next blog I shall show how it works and how it can be applied and the benefits that ensue. I shall leave you now with a simple business view of testable architecture for a simple example that was generated from a language that is unambiguous and really does specify at the right level of abstraction:
Friday, 21 November 2008
Some fun stuff
I lived and worked in the US from November 1985 to August 1987. During that time I probably learned more about IT than at any other time. I worked on some cool projects met some cool people and had a great time.
I spent many a Saturday night on the lower east side of Manhattan and small bar were I listen and generally lost myself to "Joey Miserable and Worms". See the link to the left.
Normally I blog on tech stuff but this time, for fun and in memory and affection of those times I leave you Joey Miserable and the worms and Worm Opus.
I spent many a Saturday night on the lower east side of Manhattan and small bar were I listen and generally lost myself to "Joey Miserable and Worms". See the link to the left.
Normally I blog on tech stuff but this time, for fun and in memory and affection of those times I leave you Joey Miserable and the worms and Worm Opus.
Subscribe to:
Posts (Atom)