SOA in difficult times
Happenings in the recent weeks have turned many tables and raised many eyebrows. It has been a crash from fantasy to reality for many organizations in the need to make IT real, effective, cheaper, faster, cleaner. Organizations are in a hurry to get unproductive assets, esp Cap-ex, off the books.
This is a big change for suite vendors who have positioned their products to “capture” the solution space by selling software in an integrated package form, wherein many aspects aren't necessarily being utilized.
This is especially true in the case of SOA, where there is no hurry and sometime no need for components like registry, repository, accelerators, test suites and the like. These components unlike the ESB and messaging components, the WSDL, workflow and rules components may or may not be implemented. However, organizations who have bought suites already use infrastructure to run, monies to license, Op-ex (train and maintain) seemingly unused software. Points to consider
This is a big change for suite vendors who have positioned their products to “capture” the solution space by selling software in an integrated package form, wherein many aspects aren't necessarily being utilized.
This is especially true in the case of SOA, where there is no hurry and sometime no need for components like registry, repository, accelerators, test suites and the like. These components unlike the ESB and messaging components, the WSDL, workflow and rules components may or may not be implemented. However, organizations who have bought suites already use infrastructure to run, monies to license, Op-ex (train and maintain) seemingly unused software. Points to consider
- While purchasing a suite may seem economical in the short term, it is almost always more expensive in the long term. It also ties you into vendor specific technologies which may or may not be in the best interest.
- Application and system portfolio rationalization does not impact IT assets bought in the last 10-20 years. It should be in place now both from a CFO function and a Governance function for current and future purchase plans. Stopping it at the door is cheaper than finding ways o decouple it
- Take a multi-pronged approach to your implementation and adoption strategy
- Invest in creating a current and future reference architecture or pattern that will create a common understanding of direction across teams and portfolios.
- Decide whether you want to go top down, bottom up or middle out. Middle out allows you to move many current investments into active strategic projects with a quicker time to market, a ready business case and better acceptance
- Break up the development tracks and owners based on the lifecycle of the component
- ESBs normally needs to be part of the corporate infrastructure and can follow the waterfall or iterative software development lifecycle
- Creating granular web services can be an agile or iterative approach based on the nature of business. E.g. media and publishing is likely to be more agile compared to banking or insurance which tend to have more iterations and luxury of time.
- Sustain an IDE which is common across the internal and external (vendors and partners) teams. Create an SDK which can be used to publish and facilitate the development through reuse v/s governance
- Testing – automate it for standards and interoperability. There are several tools for this once the functional test is done
- Instead of full fledged governance of reuse – institute Data Stewards which ensures better data quality and source systems and at the same time brings in essences of governance but with tighter and more practical controls
- A little extra planning - invest in loose coupling, with SaaS, cloud computing, BPO and virtualization becoming progressively mainstream.
