Composite Applications change the game if used properly as a tool to facilitate competition between your System Integration vendors and consultants.
In a traditional project the whole project used to follow a traditional waterfall project methodology, which was fine for the days of COBOL and batch processes. There is a lot of material around that addresses how waterfall methodologies are more akin to engineering techniques then to modern Software Engineering approaches. So I won’t go into depth here, describing the differences.
Lets assume that you agree, that more iterative and smaller scoped phases help to reduce risk of overall delivery failure and improve responsiveness to changing business requirements. If you don’t agree, email me or even better direct me to your blog, would love to debate this further with you.
I’m a believer, rightly or wrongly, that Portal technology provides a platform to allow for assemble of components into a composite application that reduces the focus from building of a framework to business functionality. That is, Portal technology accelerates the time to value for the business through empowering non-developers to complete the assembly of their environment, to meet the current working context, given that the functionality is available.
So given this, the question then becomes how quickly can the initial framework be deployed and then how quickly can new functionality be delivered that can be assembled into that framework?
The initial framework can be done quite quickly and can be grown – get experienced people and deploy quickly. Too much planning here will not uncover the issues that may be found in your environment, so its best to start doing. This will enable people to start learning about the environment to understand how to start assembling to meet the evolving requirements of their environment. In my view, its knowledge that can only be gained through actual experience.
The second part is additional functionality, so where existing portlets are not available, you will need to have custom portlets and components developed. The beauty of composite applications, is that individual portlets can be wired together to create more sophisticated functionality. This occurs not during development but when the user or an adminstrator decides.
Don’t use one organisation to develop your portlets to achieve the functionality of the overall system, unless you have no other option. Investigate the possibility of creating a component bid market, utilising local and possible geographically distributed teams, be they be in the Americas, Australia, India or China etc. Each component would be specified by a team and sent to the members of the bid market, you can decide the criteria for acceptance of a successful offer be it cost, time frame, consistent past record are a few items that come to mind. Competition never hurt any one and this approach then allows for change based on feedback from real world usage as the community uses the original components developed.
Just think of all the money that is not being spent by the original consulting organisation raising a plethora of Change Requests. Am hoping I’ve explained enough here to give you some ideas for reducing the costs associated with composite applications.
If you have some success stories, in this area, please leave a comment.
Nick Hortovanyi's blog 