Just had a session at TechEd with the SAP guy who is heading up the development of the GALAXY Process tool that was announced yesterday at TechEd and it was a very interesting and frank session.
Thanks to Marilyn Pratt for sorting it out at the BPX club house.
Things I thought I heard (although I might be wrong) :-
1) Galaxy has a long term roadmap to become a process abstraction layer for SAP – you change the process model and the deployed system changes…cool
2) Initially the focus is "Edge" type Composition for processes outside the core SAP processes, the core maybe exposed later
3) BPMN as a model language – so that both business and IT can understand
4) Tool uses Eclipse so that developers and BPX, work together on the same model – no throwing the model over the wall
5) CAF Guided Procedures will be replaced – but can be used today – Galaxy is still some way off (12 – 18 months)
6) ccBPM will be replaced eventually once the process engine has been proved, but investment in BPEL models will be protected
7) The tool is about modelling and operation of processes. There is still a space for Enterprise modelling tools which model conceptual processes / optimise processes and include other perspectives.
8) Usage of the new rules engine (Yasu) will be key to reducing complexity
9) Many lessons have been learned from tools like CAF and ccBPM, easy usage is key
I think we can expect big things……
Thursday, October 18, 2007
Thursday, September 20, 2007
One size governance kills SOA Innovation
I have found that it is a great desire of people within IT to try to find a one size fits all approach to innovation management. Unfortunately, as you have to play to the highest common denominator this can mean that innovation gets lots in a mountain of governance paperwork.
Luckily, with the advent of standards enabled enterprise SOA it is possible to keep control AND encourage fast innovation. This is possible by keeping tight control of the service producers (backends) so you know that the atomic business logic is sound and having governance over the various tools used to combine the services into Composite Applications so you know that the final application will fit into your infrastructure.
Once you have this in place you can start to allow projects to use the tools with the appropriate level of governance for the project, not in terms of the budget but in terms of the new service producers and new tools that it uses. If it creates no backend services and uses known tools it should require less governance than a project that delivers a large number of new services and uses a new composition environment.
Let me use yet another house analogy : Think of this in the same way you govern changes to your house. A quick paint job requires little planning and/or control, a major kitchen refit does not require external control but needs carefully planning and budget control, the extension you put on the front needs formal planning consent and if you knock the house down to build 3 smaller houses you might have to go to a planning committee to check all the infrastructure can cope.
Taking these concepts to enterprise SOA means we can relax the controls of some of the projects that are redecorating the existing landscape with composites that open up the system or automate collaboration. We can do this because the atomic backend services ensure that we still update the critical business objects correctly.
So in an enterprise SOA world one size does not fit all.
Luckily, with the advent of standards enabled enterprise SOA it is possible to keep control AND encourage fast innovation. This is possible by keeping tight control of the service producers (backends) so you know that the atomic business logic is sound and having governance over the various tools used to combine the services into Composite Applications so you know that the final application will fit into your infrastructure.
Once you have this in place you can start to allow projects to use the tools with the appropriate level of governance for the project, not in terms of the budget but in terms of the new service producers and new tools that it uses. If it creates no backend services and uses known tools it should require less governance than a project that delivers a large number of new services and uses a new composition environment.
Let me use yet another house analogy : Think of this in the same way you govern changes to your house. A quick paint job requires little planning and/or control, a major kitchen refit does not require external control but needs carefully planning and budget control, the extension you put on the front needs formal planning consent and if you knock the house down to build 3 smaller houses you might have to go to a planning committee to check all the infrastructure can cope.
Taking these concepts to enterprise SOA means we can relax the controls of some of the projects that are redecorating the existing landscape with composites that open up the system or automate collaboration. We can do this because the atomic backend services ensure that we still update the critical business objects correctly.
So in an enterprise SOA world one size does not fit all.
Tuesday, June 26, 2007
The Long Tail of Applications
I have just been reading The Long Tail by Chris Anderson and one phrase in the book – Beneath Economic Viability – made me think about how current Enterprise Software requirement, design and development methods work against innovation – which is usually found somewhere in the long tail.
All the methods that I have used for requirements analysis work towards taking out differences in a process and trying to create a logical definition of a process that is modelled once and applied to the mass market.
We have all seen the impact of this on the acceptance of Enterprise Software. Some times we end up with a homogenised, bland solution that doesn’t quite fit everyone but does the job. Over time people work round the system running their “unique” processes in Shadow IT on spreadsheets etc. If we are really unlucky we get a solution that fits one set of users really well (usually those who were most vocal in the design process) and is a mismatch for those rolled in later who get no budget for changes.
Taking a lead from Chris Anderson we need 3 things to make sure that the long tail can be exploited :-
1) Democratise Production – We need to make sure that the tools to create new applications are widely available and easy to consume. YouTube is successful because ANYONE can create a movie now.
2) Democratise Distribution – Once you have created your application it needs to be easy to get it into the market place. This is what Amazon does to make 100,000’s of books available – some of which aren’t printed until you order them.
3) Connect Supply and Demand – With all the content that is available it becomes important to have ways to filter and connected related Applications. This is how iTunes drives recommendations for music you may never have listened to by analysing the community of individuals that it believes are most like you.
With the above in place it is possible to start to move the Line of Economic Viability so that the number of users for an application might only be small but the value it creates for them (and ultimately the organisation) can be large.
The good news is that many of the patterns we see in the commercial world are moving into the software world and the shoots of each of these traits is beginning to be seen…..if you look hard enough.
All the methods that I have used for requirements analysis work towards taking out differences in a process and trying to create a logical definition of a process that is modelled once and applied to the mass market.
We have all seen the impact of this on the acceptance of Enterprise Software. Some times we end up with a homogenised, bland solution that doesn’t quite fit everyone but does the job. Over time people work round the system running their “unique” processes in Shadow IT on spreadsheets etc. If we are really unlucky we get a solution that fits one set of users really well (usually those who were most vocal in the design process) and is a mismatch for those rolled in later who get no budget for changes.
Taking a lead from Chris Anderson we need 3 things to make sure that the long tail can be exploited :-
1) Democratise Production – We need to make sure that the tools to create new applications are widely available and easy to consume. YouTube is successful because ANYONE can create a movie now.
2) Democratise Distribution – Once you have created your application it needs to be easy to get it into the market place. This is what Amazon does to make 100,000’s of books available – some of which aren’t printed until you order them.
3) Connect Supply and Demand – With all the content that is available it becomes important to have ways to filter and connected related Applications. This is how iTunes drives recommendations for music you may never have listened to by analysing the community of individuals that it believes are most like you.
With the above in place it is possible to start to move the Line of Economic Viability so that the number of users for an application might only be small but the value it creates for them (and ultimately the organisation) can be large.
The good news is that many of the patterns we see in the commercial world are moving into the software world and the shoots of each of these traits is beginning to be seen…..if you look hard enough.
Wednesday, April 11, 2007
4 Killer Questions a CIO should ask his people…
1) Do you understand the Organisations Goals and how the IT strategy / Target Architecture helps to enable these ?
2) Do you believe that the IT strategy / Target Architecture will help to enable the Organisations Goals ?
3) Please explain how your activities are helping to achieve the IT strategy / Target Architecture ?
4) What skills do you have to help me achieve the IT strategy / Target Architecture ?
The answers to these 4 questions will help to inform your Communication and Change Management plan - the importance of which is discussed in this interesting blog by Sam Lowe - I will be trying to get along to see him at the Enterprise Architect Open Group Conference in Paris
2) Do you believe that the IT strategy / Target Architecture will help to enable the Organisations Goals ?
3) Please explain how your activities are helping to achieve the IT strategy / Target Architecture ?
4) What skills do you have to help me achieve the IT strategy / Target Architecture ?
The answers to these 4 questions will help to inform your Communication and Change Management plan - the importance of which is discussed in this interesting blog by Sam Lowe - I will be trying to get along to see him at the Enterprise Architect Open Group Conference in Paris
Saturday, April 07, 2007
Governance is NOT the answer
I have just had a major operation on my neck and it now looks like the picture below.
Before the operation I had been having discussion with many people over a number of months about the importance of governance in achieving the benefits of Enterprise SOA.......following the operation I think many people (most of whom sell some kind of Governance Consulting Service) have latched on to Governance not because it is the answer but because it is the easiest thing to consult in without actually having to deliver any working systems (a bit cynical you may think!) – which god forbid might actually solve some real problems and (wait for it) ADD SOME VALUE.
The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS. If you read my blog on SDN about the lack of “real” IT professionals you will start to see what I think is the biggest problem with making SOA work……it is a lack of IT professionals !!!
It is these REAL IT Professionals who have experience, passion and vision that will be able to breath life into your new Enterprise SOA solutions. Nothing of any value EVER happens ANYWHERE if the group of people trying to achieve it don't have passion and vision (experience usually helps but is not a necessity – or we would never achieve anything new). Look at Iraq – the place has about as much Governance as you could throw at a place......but until you have a shared vision of the Target then it will be like nailing jelly to the wall….my advice to the Coalition is spend more time getting the Target vision sorted (it worked in Northern Ireland).
Anyway here is the KILLER question for those of you out there is CIO land…
WHEN YOU LOOK AT YOUR CURRENT TEAM AND YOUR CURRENT “PARTNERS” HOW MANY OF THEM HAVE THE EXPERIENCE, PASSION AND VISION YOU NEED TO ADD VALUE ?
I think you know the answer already :-)
You should promote the ones that do.....or you could commission yet another SOA Governance Study, Define a Charter for your SOA Competency Centre or Implement a Services Repository no-one will ever use.
Enterprise SOA will be achieved through expertise, passion and shared vision.
p.s If you do have a team who has Experience, Passion and Vision – can I have a job ☺
Before the operation I had been having discussion with many people over a number of months about the importance of governance in achieving the benefits of Enterprise SOA.......following the operation I think many people (most of whom sell some kind of Governance Consulting Service) have latched on to Governance not because it is the answer but because it is the easiest thing to consult in without actually having to deliver any working systems (a bit cynical you may think!) – which god forbid might actually solve some real problems and (wait for it) ADD SOME VALUE.
The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS. If you read my blog on SDN about the lack of “real” IT professionals you will start to see what I think is the biggest problem with making SOA work……it is a lack of IT professionals !!!
It is these REAL IT Professionals who have experience, passion and vision that will be able to breath life into your new Enterprise SOA solutions. Nothing of any value EVER happens ANYWHERE if the group of people trying to achieve it don't have passion and vision (experience usually helps but is not a necessity – or we would never achieve anything new). Look at Iraq – the place has about as much Governance as you could throw at a place......but until you have a shared vision of the Target then it will be like nailing jelly to the wall….my advice to the Coalition is spend more time getting the Target vision sorted (it worked in Northern Ireland).
Anyway here is the KILLER question for those of you out there is CIO land…
WHEN YOU LOOK AT YOUR CURRENT TEAM AND YOUR CURRENT “PARTNERS” HOW MANY OF THEM HAVE THE EXPERIENCE, PASSION AND VISION YOU NEED TO ADD VALUE ?
I think you know the answer already :-)
You should promote the ones that do.....or you could commission yet another SOA Governance Study, Define a Charter for your SOA Competency Centre or Implement a Services Repository no-one will ever use.
Enterprise SOA will be achieved through expertise, passion and shared vision.
p.s If you do have a team who has Experience, Passion and Vision – can I have a job ☺
Friday, April 06, 2007
BETA Version or BETTA (BETTER) Version
This is the definition of a BETA version from Wikipedia
"A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black-box testing."
However thanks to the shop assistant (let's call him Shopii) at the Game Station where I just purchased my Nintendo Wii (for the kids...if you haven't played one you REALLY need to....) I think I have hit upon a better definition.
This is how the conversation went....
Mii - "Do you know what I need to do to get my Wii on-line"
Shopii - "Great news - it is all built in - if you have wireless at home then you are up and running"
Mii - "Cool - this Wii just gets better and better - I had assumed that would need to buy another box"
Shopii - "One word of warning the Browser is a BETA version - which means that it is gonna get BETTA !!!"
Mii - "Cool Dude - Bye (actually I didn't say this bit as I was laughing too much)"
Now I think this is a MUCH better definition of BETA....we are releasing this software to you and it is going to get BETTA...perhaps this is what Microsoft have been doing all the time....we thought BETA meant almost finished....but they meant we need to make it better :-)
Roll on BETTA software....Thanks Shopii
"A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black-box testing."
However thanks to the shop assistant (let's call him Shopii) at the Game Station where I just purchased my Nintendo Wii (for the kids...if you haven't played one you REALLY need to....) I think I have hit upon a better definition.
This is how the conversation went....
Mii - "Do you know what I need to do to get my Wii on-line"
Shopii - "Great news - it is all built in - if you have wireless at home then you are up and running"
Mii - "Cool - this Wii just gets better and better - I had assumed that would need to buy another box"
Shopii - "One word of warning the Browser is a BETA version - which means that it is gonna get BETTA !!!"
Mii - "Cool Dude - Bye (actually I didn't say this bit as I was laughing too much)"
Now I think this is a MUCH better definition of BETA....we are releasing this software to you and it is going to get BETTA...perhaps this is what Microsoft have been doing all the time....we thought BETA meant almost finished....but they meant we need to make it better :-)
Roll on BETTA software....Thanks Shopii
Thursday, March 15, 2007
SOA Toddler Syndrome
Been a while since I blogged…life has been busy at work and home.
Anyway both of these have inspired another blog entry on the topic of sharing things.
My children are now 4 and 7 and as you can imagine they argue a lot about sharing toys (actually anything!), and this made me reflect to some of my work experiences trying to get organisations to put in place the required Organisation and Governance structures to encourage people to share IT assets which is at the core of the payback of any SOA/Platform IT strategy.
However you can’t make people share things as I know to my cost with my two children. However depending upon the maturity of the children I have different strategies to encourage sharing.
When they were less than 4 the strategies included :-
Bribery : Offer them some sweets / TV if they share with others
Distraction : Move their attention to something else so the other toy can be used by another child
Time-Out : Remove access to the toy for a short period of time
Now they are over 4 these strategies apply but we can also start to add more subtle strategies like :-
Free Toys : Explaining that if they share their toys they will get access to others toys free of charge
Interesting Games : Explain that if they share more children will want to play more interesting games with them
I am sure I could go on, but the point of this blog is that my very recent experience is that all of these strategies can be applied to change management strategies regarding SOA. However if you have a very immature client the “over 4” strategies may fail as they have not yet learned that simple sharing can bring benefits…before they move to more complex sharing and swapping.
Anyway both of these have inspired another blog entry on the topic of sharing things.
My children are now 4 and 7 and as you can imagine they argue a lot about sharing toys (actually anything!), and this made me reflect to some of my work experiences trying to get organisations to put in place the required Organisation and Governance structures to encourage people to share IT assets which is at the core of the payback of any SOA/Platform IT strategy.
However you can’t make people share things as I know to my cost with my two children. However depending upon the maturity of the children I have different strategies to encourage sharing.
When they were less than 4 the strategies included :-
Bribery : Offer them some sweets / TV if they share with others
Distraction : Move their attention to something else so the other toy can be used by another child
Time-Out : Remove access to the toy for a short period of time
Now they are over 4 these strategies apply but we can also start to add more subtle strategies like :-
Free Toys : Explaining that if they share their toys they will get access to others toys free of charge
Interesting Games : Explain that if they share more children will want to play more interesting games with them
I am sure I could go on, but the point of this blog is that my very recent experience is that all of these strategies can be applied to change management strategies regarding SOA. However if you have a very immature client the “over 4” strategies may fail as they have not yet learned that simple sharing can bring benefits…before they move to more complex sharing and swapping.
Subscribe to:
Posts (Atom)