New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
The Industrialization of Software Delivery
Posted by Boris Lublinsky on Aug 16, 2008
According to Ian Thomas, IT has consistently failed to deliver expected value time and time again. Ian believes that we
all need to recognise these trends and learn the lessons of industrialisation from other more mature industries.
Elaborating on previous work Ian Thomas discusses requirements for industrialization of software delivery along with the ways of achieving it.
Ian starts by defining his views about industrialization in platforms - Platform as a Service (PaaS) - and software - Software as a Service (SaaS) - delivery
we are on the verge of some huge changes in the IT industry and that we’re only just seeing the very earliest signs of these through the emergence of SOA, Web 2.0 and SaaS/PaaS. I believe that organizations are going to be forced to reform and disaggregate and that technology will become increasingly commoditized... Software as a Service is starting to prove that there are models that allow us to deliver the same function to many people with lower costs born of economies of scale and we are all going to have to finally recognize that everyone is not special, that they don’t need that customization or tailoring for 80% of what they do and that SOAs assistance in refocusing on business value will draw out the lunacy of many IT investments
According to Ian, one of the important trends is continuous componentization of business:
Over the last 100 years we’ve seen a gradual shift towards concentration on smaller levels of business organization due to the decreasing costs of executing transactions with 3rd parties ... the web is sending these transaction costs into free fall ... this is going to trigger yet another reduction in business aggregation and cause us to focus on a smaller unit of business granularity - the capability
These smaller business units, on one hand are significantly more agile, due to better understanding of the value that they can provide, and on another hand are significantly more cost driven in order to excel in the market through lowering of transaction costs. The definition of such smaller business units can be done through capability-based decomposition (similar to business model definition in this reporter’s book Applied SOA).
Traditionally organizations use business processes, organizational structures or IT architectures as a way of expressing organizational design ... perhaps all three if they use an enterprise architecture method. The big problem with these views, however, is that they tell us very little about what the combined output actually is ... what is the thing that is being done, the essential business component that is being realized? ... these views of the business are all inherently unstable since they are expressions of how things get done at a point in time; as a result they change regularly and at different rates ... Capabilities bring another level of abstraction to the table; they allow to look at the stable, component parts of the organization without worrying about how they work. This gives us the opportunity to concentrate systematically on what things the organization needs to do ... in terms of outputs and commitments ... without concerning ourselves with the details of how these commitments will be realized.... Essentially they are an expression of intent and express strategy as structure.
As a result of being cost driven, capability owners will be looking for IT solutions both internally and externally, trying to answer the following:
- Is there anyone who can provide this capability to me externally to the level of performance that I need - for instance SaaS or BPU offering available on a usage or subscription basis; or
- Finding who can help me to realize my capability as rapidly, reliably and cost effectively as possible/li>
Such an approach to IT capabilities will emphasize the importance of "capabilities realization platform" - a standardized assembly, capable of housing capabilities, implemented by different vendors using different technologies.
Such realization platforms ... require us to bring infrastructure, application, business and service management disciplines into an integrated, reliable and scalable platform for capability realization, reflecting the fact that service delivery is actually an holistic discipline and not a technology issue. Most critically ... at least from our perspective - this platform needs to be highly industrialized; built from repeatable, reliable and guaranteed components in the infrastructure, application, business and service dimensions to guarantee successful outcomes to our customers
In his post Ian describes major components of such a platform, which is an extended version of the Enterprise Service Bus (ESB), with the addition of:
service factory - a highly templatized modeling and development environment that drives people from a conceptual view of the capabilities to be realized down through a process of service design, realization and deployment against a set of architectural and development patterns represented in DSLs. These DSLs could be combinations of UML profiles, little languages or full DSLs implemented specifically for the service domain
The industrialization of software delivery has been covered in multiple publications in the last 10 years. Ian’s post describe practical steps for moving towards this vision through specific decomposition techniques and software platforms like TRIOLE
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
No comments
Watch Thread Reply