- Perception: a multitude of services comprises an architecture.
- Reality: services built as part of an SOA initiative need to be managed, governed, and secured or else the result is scattered and poorly integrated services working against each other.
Thursday, April 12, 2007
SOA Management Misconceptions
Interesting article published by Actional that lists the top 10 misconceptions. Particularly:
Tuesday, April 10, 2007
SOA - Stir Oats & Acknowledge
It has been a while, but I have been busy expanding my photography collection (which can be seen following this link), so I have been away from the computer most of the Easter week. But it is good - refreshing ! - gives me good perspective to analyse Robin Harris's article on SOA and why is it dead from inception.
At first, I found it a bit strange to start an article about SOA referring to ILM, that is until I saw where is that Robin Harris' expertise lies: he is in charge of ZdNet's storage sections.
So I remember ILM - and I am still waiting to see who has the money to implement it - multi-tiered storage is still very expensive to implement (for the average enterprise at least), and it solves a problem (ever heard of the reasons for SoX compliance for traceability and accountability or the case of the email lost by Intel): you keep relevant data for your business AWAY from your service delivery platform - until it is required and then move back again to where it needs to be processed. And yes, you can claim that applications could be developed to take the life cycle of information into consideration - but that would make them more complex to implement, so rather than increase the complexity in the software layer, let's implement information life cycle as a different aspect in a different dimension (storage handles it on behalf of the applications).
The demand side of the equation
But enough of ILM, he talks about SOA. So if we start from the beginning - if the enterprise is not developing software, it means that it requires no change - hence it doesnt'need SOA. But problem is, most enterprises have delivered solutions with timescales, mostly poorly designed, with budget constraints (see "Why projects fail"), projects have been failing since before SOA and CORBA - and shamefully most will continue failing after SOA and CORBA (See the "CHAOS Report" from 1994 by the Standish Group). Failures are not only the ones listed above, it is the fact that solutions are thought tactically and developed tactically, when they should be thought strategically and developed tactically.
No way to show a return
SOA is all about evolution - and decoupling design from implementation (remember - "highly cohesive, loosely coupled"), you don't pay for SOA 'upfront' ... you pay for the technology - the same way you pay for a database - not for the data models!!!! OOP failed at the big scale because the granularity is too fine, each department had it's own agenda and schedule - it is like blaming Java or C for failures because enterprises use a mixture of not only languages, but operating systems, repositories, methodologies & IDE tools.
Assessment: you will show as much return on a SOA effort as you can show on any new project - if the project lacks business case, SOA lacks business case for your organization.
SOA increases execution variability
Once a service has been developed it is possible to get a average response times under different loads - the implementation of the service is the same as an API in C++, EJB in Java or stored procedure inside a database - if the design gives room for non-deterministic behaviour, you will get it, disregarding the fact that it COULD be implemented in a highly deterministic way (obvious room for some peaks under different circumstances during different scenarios).
Assessment: if your software executes with high variability - it will do disregarding of SOA, it is a problem in your design and/or implementation, don't go blaming the technology.
“They make you feel cool. And hey. I met you. You are not cool.” Almost Famous
Obvious, the usual enterprise IT is not - see the case of customer relationship management - everyone thought they were unique, needing to treat customers in a unique, bespoke way - increased costs of development, lacked standardization, created highly customised pieces of software - a new release came and ... you guessed ! all the software had to be thrown as it wasn't portable due to the bespoke, unique customisations. But as a matter of fact, what is so different in the insurance market ? 90 to 95 percent should be the same standard business processes (see in telecommunications eTOM, NGOSS, etc.) ... the fact is that if you create a pattern, your software becomes commodity ... THAT IS WHAT IS COOL - making your software behave like bricks for the organisation.
Assessment: I can't save this one, lacks fundamentals - iPods and SOA are unrelated, period.
The Storage Bits take
Here the point of SOA is hit, only if briefly - you can estimate more accurately the development of a business enabling service (i.e. of the type "createSubscriber" that non technical people will understand and can trace through their use cases). Once you have elaborated on the business components that this service touch, you can give a cost assessment ("LOB dollars") - but one advantage of the decoupling is that once you have created (if you know how) a service with a version, all your applications depending of that specific service and specific version can continue being operational when new versions come along, you can do this in any technology (i.e. CORBA), but truth is that the platform agnostic web services are the ones that give you a method that really achieves this flexibility.
Assessment: As I said, touches the point of SOA, only if briefly.
At first, I found it a bit strange to start an article about SOA referring to ILM, that is until I saw where is that Robin Harris' expertise lies: he is in charge of ZdNet's storage sections.
So I remember ILM - and I am still waiting to see who has the money to implement it - multi-tiered storage is still very expensive to implement (for the average enterprise at least), and it solves a problem (ever heard of the reasons for SoX compliance for traceability and accountability or the case of the email lost by Intel): you keep relevant data for your business AWAY from your service delivery platform - until it is required and then move back again to where it needs to be processed. And yes, you can claim that applications could be developed to take the life cycle of information into consideration - but that would make them more complex to implement, so rather than increase the complexity in the software layer, let's implement information life cycle as a different aspect in a different dimension (storage handles it on behalf of the applications).
The demand side of the equation
But enough of ILM, he talks about SOA. So if we start from the beginning - if the enterprise is not developing software, it means that it requires no change - hence it doesnt'need SOA. But problem is, most enterprises have delivered solutions with timescales, mostly poorly designed, with budget constraints (see "Why projects fail"), projects have been failing since before SOA and CORBA - and shamefully most will continue failing after SOA and CORBA (See the "CHAOS Report" from 1994 by the Standish Group). Failures are not only the ones listed above, it is the fact that solutions are thought tactically and developed tactically, when they should be thought strategically and developed tactically.
No way to show a return
SOA is all about evolution - and decoupling design from implementation (remember - "highly cohesive, loosely coupled"), you don't pay for SOA 'upfront' ... you pay for the technology - the same way you pay for a database - not for the data models!!!! OOP failed at the big scale because the granularity is too fine, each department had it's own agenda and schedule - it is like blaming Java or C for failures because enterprises use a mixture of not only languages, but operating systems, repositories, methodologies & IDE tools.
Assessment: you will show as much return on a SOA effort as you can show on any new project - if the project lacks business case, SOA lacks business case for your organization.
SOA increases execution variability
Once a service has been developed it is possible to get a average response times under different loads - the implementation of the service is the same as an API in C++, EJB in Java or stored procedure inside a database - if the design gives room for non-deterministic behaviour, you will get it, disregarding the fact that it COULD be implemented in a highly deterministic way (obvious room for some peaks under different circumstances during different scenarios).
Assessment: if your software executes with high variability - it will do disregarding of SOA, it is a problem in your design and/or implementation, don't go blaming the technology.
“They make you feel cool. And hey. I met you. You are not cool.” Almost Famous
Obvious, the usual enterprise IT is not - see the case of customer relationship management - everyone thought they were unique, needing to treat customers in a unique, bespoke way - increased costs of development, lacked standardization, created highly customised pieces of software - a new release came and ... you guessed ! all the software had to be thrown as it wasn't portable due to the bespoke, unique customisations. But as a matter of fact, what is so different in the insurance market ? 90 to 95 percent should be the same standard business processes (see in telecommunications eTOM, NGOSS, etc.) ... the fact is that if you create a pattern, your software becomes commodity ... THAT IS WHAT IS COOL - making your software behave like bricks for the organisation.
Assessment: I can't save this one, lacks fundamentals - iPods and SOA are unrelated, period.
The Storage Bits take
Here the point of SOA is hit, only if briefly - you can estimate more accurately the development of a business enabling service (i.e. of the type "createSubscriber" that non technical people will understand and can trace through their use cases). Once you have elaborated on the business components that this service touch, you can give a cost assessment ("LOB dollars") - but one advantage of the decoupling is that once you have created (if you know how) a service with a version, all your applications depending of that specific service and specific version can continue being operational when new versions come along, you can do this in any technology (i.e. CORBA), but truth is that the platform agnostic web services are the ones that give you a method that really achieves this flexibility.
Assessment: As I said, touches the point of SOA, only if briefly.
Tuesday, April 03, 2007
Monday, March 19, 2007
Google on the Groove
Very interesting article, but there are plenty of conditions that have changed between the pre-Microsoft era (and their subsequent 'golden period' of win95-win2000) to what Google faces today, before the Internet took off it was easier to have "control" over your peers and partners - today's everything is so connected that your worst business nightmare might be incubating around the corner, or around the clock - and the fact that it is a so connected world not only enables faster rate of change, also enables to have stealth mode developments whilst bigger companies have to continue with the traditional publicity.
It is conspicuous the reference 'What can Google do to make its growth strategy fit better into a long term Googley development "groove"?' ... is Ballmer referring to Ray Ozzie's GROOVE ? Maybe in the 21st century, Microsoft 'grooves' there :)
It is conspicuous the reference 'What can Google do to make its growth strategy fit better into a long term Googley development "groove"?' ... is Ballmer referring to Ray Ozzie's GROOVE ? Maybe in the 21st century, Microsoft 'grooves' there :)
Saturday, March 10, 2007
And the toy of the moment is ...
The delicious Sony vaio VGN-UX (1XN in the UK):
I've been using it for a week and my only complain so far is the fact that in extremely light conditions, you will get a headache if you need to do some work (I've been using it from the hotel room at night and with dim lights it is great fun!).
Obviously to write some serious document, nothing beats the external keyboard - but even with my 17" laptop, i find after 30 minutes my wrists are aching, so the external keyboard is necessary then as well !
Obviously to write some serious document, nothing beats the external keyboard - but even with my 17" laptop, i find after 30 minutes my wrists are aching, so the external keyboard is necessary then as well !
Monday, February 26, 2007
Impressive Device
Having a look at some lightreading articles ran into Jeff Han's "interface-free," touch-driven computer screen, which can be manipulated intuitively with the fingertips, and responds to varying levels of pressure, quite an impressive piece of kit !
On top of all the potential (i.e. the usual sex driven devices!) i think his point around data visualisation is a key one - plotting complex data mining information and allowing the end-user to manipulate it using a tool like that will make understanding of the internals of businesses easier (hopefully).
Kudos to Jeff ! and hope to see it in the iPhone soon ;)
On top of all the potential (i.e. the usual sex driven devices!) i think his point around data visualisation is a key one - plotting complex data mining information and allowing the end-user to manipulate it using a tool like that will make understanding of the internals of businesses easier (hopefully).
Kudos to Jeff ! and hope to see it in the iPhone soon ;)
Wednesday, February 14, 2007
My new heroine, KUDOS
Oh wow ... I like how Joanna Rutkowska writes ... she's my new online heroine! In a virtual battle she would kick Mark Russinovich’s bottom !
And she's a cutie patootie:
And she's a cutie patootie:
Subscribe to:
Posts (Atom)
