I have been a supporter of Agile Software Development for many years now. The simplicity of Agile principles and practices, for me, provide an excellent framework for timely delivery of code.
Until fairly recently, application of Agile in IT, to me, has only been applicable in the area of Application software development. This is because I used to see Agile’s “Develop only what you need right now… Test first… Refactor to eliminate waste… Release often” to be extremely difficult to apply in an Enterprise context because:
Which brings me to the title of this blog “The Stories that make a Service”
To be truthful, of all the Agile approaches that I have really followed, XP is the only one that I have used in practice fully.
In XP user requirements are defined as “User Stories”.
As such “User Stories”, to which I will further refer to as “Stories”, are the building blocks for systems developed using XP.
For the purpose of this exercise, it is important to understand that I see an information system as a giant ensemble of Consumers and Producers of Information.
What brings Consumers and Producers together in an SOA are: Services.
A Service delivers the information required by Consumers from information provided by Producers.
Often, in order to be able to provide the information “as required” by the consumers, the information provided by the Producers needs to be “massaged” (which can mean… aggregated, transformed, or processed into derivations). It is for this reason that in an SOA, the Consumers do not obtain information from the Producers directly, but from Providers instead.
With this breakdown in Consumers, Providers and Producers, applying XP (and I believe most other Agile methodologies) has become easy.
This article explains why.
In order to understand how Stories, through the Consumer-Provider-Producer paradigm, suddenly become applicable across the Enterprise, it is important to generally make these acronyms more concrete.
An Application (i.e. a piece of software that a user interacts with) is generally seen as a consumer. There are other types of consumers, but Applications are easy to understand.
A Data Source (or Repository) is generally seen as a producer. Please note that I see a Data Source to be anything that provides data (a file, a database, a business rules engine...).
Services are in an SOA deemed the Providers. Services provide their Consumers with the ability to manage (create, retrieve, update and delete) information that is maintained by Data Sources.
Just as functionality within an Application can be described by its users using Stories, Services can be described by business representatives using Stories.
Instead of each Story describing part of the process of using an Application, in the SOA a Story will mainly describe a part of the Business Process within the Enterprise.
Because, in using SOA there is no translation required from Business Requirements to IT Components, each (technically) delivering part of the Business Process, but rather, the Business Process is defined as a ensemble of Services, the Story paradigm can effectively be put to work.
The principle being: “The Business, understands their Business Process best and is therefore the most capable of describing the Business Process in terms of Business Tasks and group these Business Tasks together in a way that they make business sense in terms of the business process”.
If a Story represents the afore mentioned grouping of Tasks, each story then represents a Service.
The beauty of it is that:
Until fairly recently, application of Agile in IT, to me, has only been applicable in the area of Application software development. This is because I used to see Agile’s “Develop only what you need right now… Test first… Refactor to eliminate waste… Release often” to be extremely difficult to apply in an Enterprise context because:
- It was hard for me as a “techie”, to predict changes to a system of components that underpin a business process.
- Building only for “what is needed right now” can be extremely complex, when what one system needs right now, is not necessarily what all the other systems in the complete applications landscape need “right now”
- Refactoring components in a complex system of autonomous, heterogeneous parts has significant risk to the system as a whole
Which brings me to the title of this blog “The Stories that make a Service”
To be truthful, of all the Agile approaches that I have really followed, XP is the only one that I have used in practice fully.
In XP user requirements are defined as “User Stories”.
As such “User Stories”, to which I will further refer to as “Stories”, are the building blocks for systems developed using XP.
For the purpose of this exercise, it is important to understand that I see an information system as a giant ensemble of Consumers and Producers of Information.
What brings Consumers and Producers together in an SOA are: Services.
A Service delivers the information required by Consumers from information provided by Producers.
Often, in order to be able to provide the information “as required” by the consumers, the information provided by the Producers needs to be “massaged” (which can mean… aggregated, transformed, or processed into derivations). It is for this reason that in an SOA, the Consumers do not obtain information from the Producers directly, but from Providers instead.
With this breakdown in Consumers, Providers and Producers, applying XP (and I believe most other Agile methodologies) has become easy.
This article explains why.
In order to understand how Stories, through the Consumer-Provider-Producer paradigm, suddenly become applicable across the Enterprise, it is important to generally make these acronyms more concrete.
An Application (i.e. a piece of software that a user interacts with) is generally seen as a consumer. There are other types of consumers, but Applications are easy to understand.
A Data Source (or Repository) is generally seen as a producer. Please note that I see a Data Source to be anything that provides data (a file, a database, a business rules engine...).
Services are in an SOA deemed the Providers. Services provide their Consumers with the ability to manage (create, retrieve, update and delete) information that is maintained by Data Sources.
Just as functionality within an Application can be described by its users using Stories, Services can be described by business representatives using Stories.
Instead of each Story describing part of the process of using an Application, in the SOA a Story will mainly describe a part of the Business Process within the Enterprise.
Because, in using SOA there is no translation required from Business Requirements to IT Components, each (technically) delivering part of the Business Process, but rather, the Business Process is defined as a ensemble of Services, the Story paradigm can effectively be put to work.
The principle being: “The Business, understands their Business Process best and is therefore the most capable of describing the Business Process in terms of Business Tasks and group these Business Tasks together in a way that they make business sense in terms of the business process”.
If a Story represents the afore mentioned grouping of Tasks, each story then represents a Service.
The beauty of it is that:
- Consumers (mostly applications) can be defined in Stories
- Providers (services) can be defined in Stories
- Producers (almost always within the “techie” domain) can be defined in Stories
- It is no longer hard for me as a “techie” to predict changes to a system of components that underpin a business process, because these components (i.e. Services) already represent groupings of Business Tasks that make up the Services that again make up the Business Process.
- Building only for “what is needed right now” is no longer complex, when what one system needs right now, because these systems are built on Services that underpin the Business Process for the complete applications landscape as it is “right now”
- Refactoring components, now defined and interfaced as Services in an environment that is built on these Services is now isolated on a per Service basis and will predictably affect the entire process (and therefore predictably affect each Application that “participates” in that process).
0 comments:
Post a Comment