Flat-Packed Applications - Composite Apps?
Not some new Ikea product range, but rather Owen Pettiford's thoughts on how Composite Applications have the potential to become the key 'third-way' for enterprise solutions, beyond today's well trodden 'bespoke' and 'packaged application' paths.
Of course today's conventional wisdom goes:
*If what you need is unique or not yet available then you probably need bespoke (particularly if having exactly what you need can give you a competitive advantage).
*If you need to buy-in 'best-practice', implement something that's commodising, or just need somebody else to bear the cost of maintaining/developing the solution then packaged apps are the answer.
But is it really black or white - what about all the shades of grey in between for requirements where the packaged apps aren't quite right becuase of industry or cultural specifics (but it's hardly a competitive differentiator)? What about different economic models where you don't want to bear all the cost yourself, but want to avoid funding development of a product-suite most of which you don't use? Etc etc and so on.
But Owen adds a sub-text - that it will only happen if we primarily focus on the solutions themselves with a secondary focus on the technologies and frameworks that underpin or enable them. In other words, the opposite of what the technology vendor-driven hype in the IT industry predominantly is at the moment. I think he's right.
Technorati Tags: Composite Applications Composite Apps Enterprise IT Enterprise Applications SOA Service Oriented Services Architecture
Of course today's conventional wisdom goes:
*If what you need is unique or not yet available then you probably need bespoke (particularly if having exactly what you need can give you a competitive advantage).
*If you need to buy-in 'best-practice', implement something that's commodising, or just need somebody else to bear the cost of maintaining/developing the solution then packaged apps are the answer.
But is it really black or white - what about all the shades of grey in between for requirements where the packaged apps aren't quite right becuase of industry or cultural specifics (but it's hardly a competitive differentiator)? What about different economic models where you don't want to bear all the cost yourself, but want to avoid funding development of a product-suite most of which you don't use? Etc etc and so on.
But Owen adds a sub-text - that it will only happen if we primarily focus on the solutions themselves with a secondary focus on the technologies and frameworks that underpin or enable them. In other words, the opposite of what the technology vendor-driven hype in the IT industry predominantly is at the moment. I think he's right.
Technorati Tags: Composite Applications Composite Apps Enterprise IT Enterprise Applications SOA Service Oriented Services Architecture
posted by Sam Lowe at
8:59 pm
4 Comments:
Cannot agree with you more. Yes indeed, we need more of composite apps. But do you think we have technology mature enough to specify components to such level of details that one can compose them just based on specifications provided? I guess not. What we have right now is some level of meta-data that is well understood within limited context. Forget automatic composition, we can only do manual composition. And finally, we rely on testing to verify the composition. Which defeats the whole idea of being able to compose. Since original components were thoroghly tested, we need not test the composition. (Well atleast thats how 'Ikea' works!). I have blogged here about requirement management, which alludes to why it might be difficult to get component specification right. It is a long way off to the composite app. nirvan, if you ask me.
By
Anonymous, at 9:10 am
Cannot agree with you more. Yes indeed, we need more of composite apps. But do you think we have technology mature enough to specify components to such level of details that one can compose them just based on specifications provided? I guess not. What we have right now is some level of meta-data that is well understood within limited context. Forget automatic composition, we can only do manual composition. And finally, we rely on testing to verify the composition. Which defeats the whole idea of being able to compose. Since original components were thoroghly tested, we need not test the composition. (Well atleast thats how 'Ikea' works!). I have blogged here about requirement management, which alludes to why it might be difficult to get component specification right. It is a long way off to the composite app. nirvan, if you ask me.
By
Anonymous, at 9:11 am
Cannot agree with you more. Yes indeed, we need more of composite apps. But do you think we have technology mature enough to specify components to such level of details that one can compose them just based on specifications provided? I guess not. What we have right now is some level of meta-data that is well understood within limited context. Forget automatic composition, we can only do manual composition. And finally, we rely on testing to verify the composition. Which defeats the whole idea of being able to compose. Since original components were thoroghly tested, we need not test the composition. (Well atleast thats how 'Ikea' works!). I have blogged here about requirement management, which alludes to why it might be difficult to get component specification right. It is a long way off to the composite app. nirvan, if you ask me.
By
Anonymous, at 9:12 am
It's a good question Vilas.
In fact I'd go further, I suspect the frameworks to define the different types of components and how they relate to each other are weak at the moment.
I'd suggest that without agreed ways of defining the types of 'policies' that need to be applied at the 'joins' between each component it is always going to be difficult to rely on testing at the component level, and therefore discretionary requirements definition, manual oversight and regression testing is going to be a requirement.
But this will change over time (possibly a short time) when some of the more unhelpful sacred cows get killed.
This all said, I do believe that even now, at the enterprise level (rather than the solution level) the advantages outweigh the disadvantages in many circumstances as it is better than the continued proliferation and duplication alternative.
By
Sam Lowe, at 3:54 pm
Post a Comment
via Haloscan
<< Home