5 new skills SOA practitioners need
Part of the ritual of engagement of architects with their peers is a pre-emptive declaration of knowing contempt for the latest buzzword. Service Oriented Architecture /BPM has been a real need-filler in this area. What better way to instantly declare your mastery of all things architecture than to knowingly preface every conversation with a world weary "UML is so-oo overrated" or "Oh not this SOA hype again ". Such sentiments signal a mastery of the subject to those less able and instantly define the guru-acolyte dynamics in an interaction.
Well this has been happening a lot lately so, fed up of the "SOA is just the same old stuff just hyped up" hype, I decided to launch this blog into cyberspace by defining why this SOA thing is not just the same old techniques packaged up in new garb. Here are 5 things that SOA practioners need to master and yes, they have evolved in the last ten years.
1. Process based thinking.
Yes I know processes analysis has been around for ever. However, the use of top down Process based thinking leading to systems design on a widespread scale is a recent development caused by the emergence of tools and the development of industry standards at roughly the same time.
Building an understanding of the nature of process design and re-engineering and assessing where BPM and SOA tools can and cannot help is very much a 21st century skill.
2.Composition based design.
Dashing all hopes that the phrase paradigm shift died of natural causes in the OO era, allow me to resurrect it for a sentence and say that composing efficient processes and systems using independent, autonomous services that have no awareness of each other is a new technique for architects to master. There is a definite skill in being able to combone loosely coupled , always running services to deliver business logic. A new mindset is required to understand issues of state management , process orchestration and business rules in delivering effective solutions using composed designs and creating metadata based business process logic without relying on a shared process space ( as in traditional programming methodologies).
3. Investment justification and value assessment
SOA and BPM initiatives require investment in infrastructure - often significant. Enterprise architects need to be able to make the case for platform investment for these initiatives to lead the business and need new skills in valuing the flexibility. They key benefits SOA and BPM platforms provide is future flexibility and an Enterprise architect needs to be at least conversant with non traditional means of investment valuation like Real Options. Stndard NPV and IRR based techniques that work on the basis of determininstic projections of cost and benefits are inadequate in valuing the flexibility that comes with a platform than can open up opportunities for future initiatives that are difficult to accurately value at this point in time. The inherent value of this option needs to be valued and communicated in business terms and it is a skill EA practitioners increasingly have to come to terms with. Expect this to become increasingly mainstream in the future.
4.Buzzword mastery
The ability to distill out the few nuggets of sense that lie behind the constant buzzword assault on the senses is more important than ever in the SOA/BPM space. Unconvinced ? Allow me to challenge you with a small sample of acronyms you would normally expect to be able to make sense of on a day to say basis ( I'll leave SOA and BPM out)
ESB, BPML,UML, OMG,MDA,REST,SOAP,ATOM,RSS,AOP, SOMM
(That last one I overheard at a particularly "kid-you-not" moment at a conference - stands for Service Oriented maturity Model whatever that means).
Now expected to be confronted constantly with the following questions as an architect by earnest and sincere sounding folk :
What is our (insert acronym from list above) strategy ? and expect to be able to give a diplomatic and equally polite response.
Which leads us nicely to .....
5. Problem definition
A large number of questions Enterprise architects spend time tackling have to do with a particularly bizarre variation on applied Ideonomy , that weird science of taking any bunch of terms and combining them to form a proposition - whether it has meaning or not.
Like this sentence , a lot of the propositions around SOA and BPM are nonsense cloaked in rational sounding structures.
"What is our SOA strategy" is merely one such form of this logical trap ( cunningly implying that there is obviously some value in having an SOA/ESB/BPM strategy). I'll leave finding other such nonsensical statements as an exercise to the discerning reader.
Seeing through this bovine faeces and guiding discussion around to the more sensible "what is the business value of investment in SOA related technologies and do I need to do it " type discussions is also a very 21st century architect skill.
Well this has been happening a lot lately so, fed up of the "SOA is just the same old stuff just hyped up" hype, I decided to launch this blog into cyberspace by defining why this SOA thing is not just the same old techniques packaged up in new garb. Here are 5 things that SOA practioners need to master and yes, they have evolved in the last ten years.
1. Process based thinking.
Yes I know processes analysis has been around for ever. However, the use of top down Process based thinking leading to systems design on a widespread scale is a recent development caused by the emergence of tools and the development of industry standards at roughly the same time.
Building an understanding of the nature of process design and re-engineering and assessing where BPM and SOA tools can and cannot help is very much a 21st century skill.
2.Composition based design.
Dashing all hopes that the phrase paradigm shift died of natural causes in the OO era, allow me to resurrect it for a sentence and say that composing efficient processes and systems using independent, autonomous services that have no awareness of each other is a new technique for architects to master. There is a definite skill in being able to combone loosely coupled , always running services to deliver business logic. A new mindset is required to understand issues of state management , process orchestration and business rules in delivering effective solutions using composed designs and creating metadata based business process logic without relying on a shared process space ( as in traditional programming methodologies).
3. Investment justification and value assessment
SOA and BPM initiatives require investment in infrastructure - often significant. Enterprise architects need to be able to make the case for platform investment for these initiatives to lead the business and need new skills in valuing the flexibility. They key benefits SOA and BPM platforms provide is future flexibility and an Enterprise architect needs to be at least conversant with non traditional means of investment valuation like Real Options. Stndard NPV and IRR based techniques that work on the basis of determininstic projections of cost and benefits are inadequate in valuing the flexibility that comes with a platform than can open up opportunities for future initiatives that are difficult to accurately value at this point in time. The inherent value of this option needs to be valued and communicated in business terms and it is a skill EA practitioners increasingly have to come to terms with. Expect this to become increasingly mainstream in the future.
4.Buzzword mastery
The ability to distill out the few nuggets of sense that lie behind the constant buzzword assault on the senses is more important than ever in the SOA/BPM space. Unconvinced ? Allow me to challenge you with a small sample of acronyms you would normally expect to be able to make sense of on a day to say basis ( I'll leave SOA and BPM out)
ESB, BPML,UML, OMG,MDA,REST,SOAP,ATOM,RSS,AOP, SOMM
(That last one I overheard at a particularly "kid-you-not" moment at a conference - stands for Service Oriented maturity Model whatever that means).
Now expected to be confronted constantly with the following questions as an architect by earnest and sincere sounding folk :
What is our (insert acronym from list above) strategy ? and expect to be able to give a diplomatic and equally polite response.
Which leads us nicely to .....
5. Problem definition
A large number of questions Enterprise architects spend time tackling have to do with a particularly bizarre variation on applied Ideonomy , that weird science of taking any bunch of terms and combining them to form a proposition - whether it has meaning or not.
Like this sentence , a lot of the propositions around SOA and BPM are nonsense cloaked in rational sounding structures.
"What is our SOA strategy" is merely one such form of this logical trap ( cunningly implying that there is obviously some value in having an SOA/ESB/BPM strategy). I'll leave finding other such nonsensical statements as an exercise to the discerning reader.
Seeing through this bovine faeces and guiding discussion around to the more sensible "what is the business value of investment in SOA related technologies and do I need to do it " type discussions is also a very 21st century architect skill.
posted by Piyush Pant at 2:10 pm
0 Comments:
Post a Comment
<< Home