- What do you want to do - state it clearly and concisely
- Define your requirements
- Take away requirements until you don't meet the objective
So in 2008 don't ask what you can do, ask what you can't.
Technorati Tags: SOA, Service Architecture
Thursday, January 03, 2008
Take it away till it works
Back in the 90s when I was doing CORBA and GUI work there was a little mantra that I'd learnt that I can't for the life of me remember where it came from, its something however that applies equally to IT systems as it does to GUI work. Its a bit like JAGNI but its used to actively help reduce requirements. The rules are simple
So in 2008 don't ask what you can do, ask what you can't.
So in 2008 don't ask what you can do, ask what you can't.
Chairman Mao and the problems of IT
Reading the economist over Christmas (oh and seriously get a subscription) there was a great article about how Chairman Mao is an ideal "role model" for the poor quality manager. Reading it however it became clear that 90% of IT also appears to follow the way of Mao when approaching their jobs.
So if you aren't actually any good at IT then here is how to bluff your way using the Mao guide to IT. This applies to Architects, Managers, Vendors and even developers who just don't feel they have the talent to get anywhere
A powerful, mendacious slogan
For Mao it was "Serve the People", given that he "... lived like an emperor, carried on litters by peasants, surrounded by concubines and placated by everyone. this really was an impressive slogan. The point here is that the slogan is an outright lie, but its an outright lie that is talked about honestly and with conviction but doesn't bear any relationship to reality.
In IT things like "Business Focused", "Customer Service" and "Delivering value" can be used to mask what is essentially a continual drive to use new technologies and to avoid talking to the business or customers if at all possible. In fact its a case of business as usual with everything being now justified as "required" by the over arching vision.
Ummm looking at all those vendor slogans makes me think that Chairman Mao's PR department is alive and well in IT. Huge massive friendly slogans backed by software that makes you cry and costs a fortune.
Ruthless media manipulation
Have posters printed, set up a web page, have an award in fact do anything that makes it look like you are doing this while in fact doing nothing of the sort. This tends to be a real management favourite, a new initiative, a new name and the same old behaviours and thinking. A big internal email campaign, possibly even some external press and most of all controlling all of the communication that goes between IT and the business.
Ever had a manager tell you "you can't talk to the business"? Or how about "tell me what you want and I'll find out" and then become convinced that they haven't talked to the business at all? What about architects who claim to "understand the business" and therefore don't let anyone else go direct?
Other bits here are in the creation of fake statistics and successes is another area here. The classic "well it was fine when I left it" and claiming improvements in areas where there aren't any metrics being formally gathered. This is where people claim "we've improved quality/productivity/time to market by X%" when all the evidence seems to show that in fact its got worse. The key is that the person manipulating and broadcasting the stats is the person responsible for them.
In IT departments the media manipulation tends to be internal rather than with the press but its the continual planting of stories and broadcasting of success (and others failures). A few other good ones here are where a project fails but its "all the fault of the vendor" or where a technology turns out to be rubbish and that is "down to the implementation team" the key is spinning and there are lots of people in IT who seem to think that spinning is as important as delivering.
Vendors are truly the best at this in terms of their external marketing. The product might be a bug-riddled piece of crap that won't even install from the CDs but thanks to some smart marketing, demoware and presentations its lauded as being a market leader.
Sacrifice of friends and colleagues
Now here is where IT often moves away from Mao in that I tend to see Cabals and cliques being the dominant factor with competing groups battling for supremacy. But then again isn't this exactly what Mao was about? Basically using different groups within the organisation as the scapegoats? Project fails because in reality the architecture was completely rubbish? Blame the project manager, the development team or India but never, ever allow people to point out that the architecture was unimplementable.
This is something I see over and over again as IT projects fail. The finger pointing starts and the "winner" is the one who gets the least blame and places the most blame elsewhere. Again this isn't actually about reality its about using other people to take the fall for you so you don't have to admit to failure yourself.
With Vendors I guess this would be how they stab each other in the back, but I'm not sure its as good an analogy.
Activity substituting for achievement
Now this is the area where IT, and in particular Architects, come into their own. Those constant internal meetings, those document reviews and those endless process improvement efforts that never improve anything. Its hard to imagine a group of people who create more noise for little achievement that those found in IT. In 2007 I saw people proudly demonstrate how they could use WSDLs in their tools... 2007? That was done in 2001. There are all the various frameworks out there, something IT developer love to do. Don't develop the solution, develop a framework and never get around to the solution.
With vendors this is all about adding new bells and whistles to the products, and to be fair to the vendors this is what the Chairman Mao impersonators in corporate IT and the blog world are asking them to do. Its not about making it better its more like "Pimp my product" with lots of new bling being added on to the same old crap in the mistaken belief that this actually makes it better.
Part of the problem is that the talent gap in IT is ridiculously huge. There really are a huge number of people who are, when all is said and done, just bluffing at their jobs and who follow (unknowingly) Mao's plans for success on a daily basis.
IT and Chairman Mao, maybe the required reading shouldn't be The Mythical Man Month but the mass murders' Little Red Book.
So if you aren't actually any good at IT then here is how to bluff your way using the Mao guide to IT. This applies to Architects, Managers, Vendors and even developers who just don't feel they have the talent to get anywhere
A powerful, mendacious slogan
For Mao it was "Serve the People", given that he "... lived like an emperor, carried on litters by peasants, surrounded by concubines and placated by everyone. this really was an impressive slogan. The point here is that the slogan is an outright lie, but its an outright lie that is talked about honestly and with conviction but doesn't bear any relationship to reality.
In IT things like "Business Focused", "Customer Service" and "Delivering value" can be used to mask what is essentially a continual drive to use new technologies and to avoid talking to the business or customers if at all possible. In fact its a case of business as usual with everything being now justified as "required" by the over arching vision.
Ummm looking at all those vendor slogans makes me think that Chairman Mao's PR department is alive and well in IT. Huge massive friendly slogans backed by software that makes you cry and costs a fortune.
Ruthless media manipulation
Have posters printed, set up a web page, have an award in fact do anything that makes it look like you are doing this while in fact doing nothing of the sort. This tends to be a real management favourite, a new initiative, a new name and the same old behaviours and thinking. A big internal email campaign, possibly even some external press and most of all controlling all of the communication that goes between IT and the business.
Ever had a manager tell you "you can't talk to the business"? Or how about "tell me what you want and I'll find out" and then become convinced that they haven't talked to the business at all? What about architects who claim to "understand the business" and therefore don't let anyone else go direct?
Other bits here are in the creation of fake statistics and successes is another area here. The classic "well it was fine when I left it" and claiming improvements in areas where there aren't any metrics being formally gathered. This is where people claim "we've improved quality/productivity/time to market by X%" when all the evidence seems to show that in fact its got worse. The key is that the person manipulating and broadcasting the stats is the person responsible for them.
In IT departments the media manipulation tends to be internal rather than with the press but its the continual planting of stories and broadcasting of success (and others failures). A few other good ones here are where a project fails but its "all the fault of the vendor" or where a technology turns out to be rubbish and that is "down to the implementation team" the key is spinning and there are lots of people in IT who seem to think that spinning is as important as delivering.
Vendors are truly the best at this in terms of their external marketing. The product might be a bug-riddled piece of crap that won't even install from the CDs but thanks to some smart marketing, demoware and presentations its lauded as being a market leader.
Sacrifice of friends and colleagues
Now here is where IT often moves away from Mao in that I tend to see Cabals and cliques being the dominant factor with competing groups battling for supremacy. But then again isn't this exactly what Mao was about? Basically using different groups within the organisation as the scapegoats? Project fails because in reality the architecture was completely rubbish? Blame the project manager, the development team or India but never, ever allow people to point out that the architecture was unimplementable.
This is something I see over and over again as IT projects fail. The finger pointing starts and the "winner" is the one who gets the least blame and places the most blame elsewhere. Again this isn't actually about reality its about using other people to take the fall for you so you don't have to admit to failure yourself.
With Vendors I guess this would be how they stab each other in the back, but I'm not sure its as good an analogy.
Activity substituting for achievement
Now this is the area where IT, and in particular Architects, come into their own. Those constant internal meetings, those document reviews and those endless process improvement efforts that never improve anything. Its hard to imagine a group of people who create more noise for little achievement that those found in IT. In 2007 I saw people proudly demonstrate how they could use WSDLs in their tools... 2007? That was done in 2001. There are all the various frameworks out there, something IT developer love to do. Don't develop the solution, develop a framework and never get around to the solution.
With vendors this is all about adding new bells and whistles to the products, and to be fair to the vendors this is what the Chairman Mao impersonators in corporate IT and the blog world are asking them to do. Its not about making it better its more like "Pimp my product" with lots of new bling being added on to the same old crap in the mistaken belief that this actually makes it better.
Part of the problem is that the talent gap in IT is ridiculously huge. There really are a huge number of people who are, when all is said and done, just bluffing at their jobs and who follow (unknowingly) Mao's plans for success on a daily basis.
IT and Chairman Mao, maybe the required reading shouldn't be The Mythical Man Month but the mass murders' Little Red Book.
Technorati Tags: SOA, Service Architecture
Monday, December 17, 2007
Boothware
I'm doing some reviewing of JavaOne presentations at the moment (SOA/EAI) and the number of vendor presentations that are basically a booth demo where they'd like a bigger audience is just staggering. Sometimes they are dressed up as an "investigation" but most of the time its literally a standard booth demo (even including "how to install" on occasion).
Death to Boothware.
Death to Boothware.
Technorati Tags: JavaOne
Tuesday, December 04, 2007
Why corporate IT means something
Over on Joel on Software there is a post about his talk at Yale where he warns people not to go into "in-house" corporate development because its soul suckingly bad. Why?
"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.
Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.
Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).
Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?
Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons
Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.
So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.
The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.
Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.
The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.
The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".
So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.
Number one. You never get to do things the right way. You always have to do things the expedient way. It costs so much money to hire these programmers—typically a company like Accenture or IBM would charge $300 an hour for the services of some recent Yale PoliSci grad who took a 6 week course in dot net programming, and who is earning $47,000 a year and hoping that it’ll provide enough experience to get into business school—anyway, it costs so much to hire these programmers that you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be.
"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.
You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough.
Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.
Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells.
Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).
Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?
Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons
- Societal balance - by which I mean women. Tech companies are male domains and the male/female ratio is normally completely dreadful. If you work in a corporate then the odds are this will be much more balanced. This makes for a better social life
- HQs of corporates are better than tech companies. I've been to lots of the supposed "best" tech company offices and the HQ of a pharma, bank, oil company, airline or even traditional manufacturing company tend to be miles better. Now only the best in IT get to be at HQ, but were you planning on being average?
- Flying - The policies at most vendors appear to be "coach unless a VP" whereas in corporates it tends to be "we are in business so we fly in business".
Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.
So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.
The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.
Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.
The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.
The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".
So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.
Technorati Tags: SOA, Service Architecture
Monday, December 03, 2007
Christmas SOA
I've been reading some things lately that talk about business people being "in control" of process diagrams so I thought it was worth while reprising something I wrote back in 2005 and which is in the book around how there is a big difference between the perceived business process and the actual execution process.
Now I have two kids and its coming up to Christmas and their view of what happens at Christmas is of course completely different to what actually happens. The kids are the business at Christmas its all about meeting their business expectations and goals.
As the parents we have only one job to do and that is to deliver Christmas in the manner the business expects to see it. This means that we have to hide from the business the technical delivery elements and just show Lana and Louis the vision they want to see... now of course the question is how do we deliver an SOA Christmas?
At the top level 0 its all pretty simple all the business wants to see is presents coming from as many different channels as possible.
As the kids are both still young the metric that will matter is volume of presents and its by this that success will be judged.
At Level 1 they have the concept that Santa Claus is the centre of the present giving universe and it is to Santa that the list of request should be made. Santa is then responsible for distributing the list to everyone else for the things he doesn't want to get.
So at a process level the business view is that the list goes to Santa, who sends it on, there is a view that there are things called shops out there involved in some way, but that isn't important to the business. Santa then delivers presents to the stocking while the parents deliver to the tree. Any person coming through the door over this period is also expected to enable the business to get presents.
This is the perceived business process and its this that the kids want to be able to effect. Can the list be delivered in person? Emailed? Sent via some slightly dubious chat service? Or maybe posted the old fashioned way?
So at a process level the business view is that the list goes to Santa, who sends it on, there is a view that there are things called shops out there involved in some way, but that isn't important to the business. Santa then delivers presents to the stocking while the parents deliver to the tree. Any person coming through the door over this period is also expected to enable the business to get presents.
This is the perceived business process and its this that the kids want to be able to effect. Can the list be delivered in person? Emailed? Sent via some slightly dubious chat service? Or maybe posted the old fashioned way? There is a, reluctant, acceptance from the business that the 25th December is the delivery date and that this isn't movable and that some suppliers will miss the delivery date and provide presents at the first available point after the main day. Santa however is never late.
Now the goal of the parents (IT) is to deliver Christmas in the way that the kids expect and to ensure a successful and happy Christmas period.
Unfortunately the parents also know that Santa needs some manual intervention to get things moving. So first of all they have to provision the infrastructure, namely Santa and the Tree, then they have to co-ordinate the present buying to minimise duplicates. A spree of present buying is then underway, as is an increase in debt, followed by delivering the presents in the right manner to the places the business expect them to be.
This therefore is the execution process. This process might get much more complex if you have to add in balancing acts between the business people so there is the perception of present equivalence or if the parents are actually hosting Christmas this year so the workload goes through the roof. This all demonstrates that within SOA, there might be a commonality in an understanding of the services being provisioned, but the actual manner of provisioning and the additional actions are only of interest to the implementors and should be hidden from the business, and other consumers as they are irrelevant to them as long as their objectives are being met. This is one reason why SOA makes good BPM but BPM makes bad SOA
This therefore is the execution process. This process might get much more complex if you have to add in balancing acts between the business people so there is the perception of present equivalence or if the parents are actually hosting Christmas this year so the workload goes through the roof. This all demonstrates that within SOA, there might be a commonality in an understanding of the services being provisioned, but the actual manner of provisioning and the additional actions are only of interest to the implementors and should be hidden from the business, and other consumers as they are irrelevant to them as long as their objectives are being met. This is one reason why SOA makes good BPM but BPM makes bad SOA This is just one of the reasons I tend to say that business process is an IT myth. You need to understand both the business view of what must be achieved (often goal driven) and how it is measured (the implicit process) and then map this down to how IT will deliver that goal and measures (sometimes via an explicit process). In this world of separation its nonsense to argue that the business is "in control" of the execution processes beyond the level of defining the important elements of KPIs, goals and implicit process. Having this explicit process implemented within the services rather than across them (for a blog outline there is chapter on this in the book) also helps to scale as the services are coordinating effort rather than having to have a process per child.
Switching back to more normal IT should the sales director worry that that simple two steps of "check fraud then get payment" might require a complex series of processes and integration to external 3rd parties? Should the LOB manager who wants to get their current key suppliers need to know that this integrates with 20 backend systems and has a complex Master Data Management solution? No that is the reason IT is there to take the business goals and KPIs and best surface them in the way that the business wants. This is why business people shouldn't care about their BPMN diagrams being what are being executed they should just care that they are being delivered.
Remember folks, SOA isn't just for Christmas.
Technorati Tags: SOA, Service Architecture
Accenture still not getting SOA
A while back I pointed out some comments by Accenture's CTO which (for me) indicated that Accenture don't get SOA well they've now established a venture with BEA and it appears that Accenture still don't get SOA.
Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.
You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.
If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.
He [Accenture CTO Donald Rippert] described the four phases of SOA implementation, which begins at using XML as an interface, then implementing legacy systems as Web services, and then using an ESB to connect Web services and use composite processes. The fourth phase involves using BPEL (Business Process Execution Language for Web Services) in which a business application is revised by making changes to the process model rather than the code.
But SOA, for the most part, is not enabling this yet, said Rippert. "Maybe someday, but not today; I don't see it today," Rippert said.
Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.
You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.
If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.
Technorati Tags: SOA, Service Architecture
Subscribe to:
Posts (Atom)