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.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Oct 18, 2007
"... the model is potentially in danger of misdirection and ignorance rendering it a worn-out moniker that represents mere product features. That's more or less what happened to EAI, after all. Forces that might be assassinating SOA include: integration platform vendors, enterprise architects, certain industry analysts, CIOs."It's with this in mind that the latest article from ZapThink tries to put things into perspective.
"Any trend that demands such a significant portion of executives’ and practitioners’ time and budget demands to be critically examined so that the good of all parties are being met. After all, very few people benefit from trends that are all hype and no substance."According to the analysts, the most frequent cause of failure of SOA is inappropriate use. The "one size does not fit all" argument would appear to be an accurate summary of this pitfall, where companies try to use SOA across the enterprise when the business case would not be justified.
"The rationale goes that SOA is an aspect of Enterprise Architecture and therefore its scope is enterprisewide, or because it is so important and strategic, it must be implemented at an enterprisewide level. Other IT practitioners are simply used to implementing all of their major initiatives enterprisewide, so why should SOA be different? Because SOA is not a project or a technology – it is an approach, that’s why."SOA is simply not appropriate for all problems and determining when and where (and if) to apply SOA principles should always be the first step in any attempt to use SOA. The inappropriate use (or overuse) of a technology, methodology etc. has often resulted in its downfall in our industry:
"When companies seek to implement hundreds of unproven Services against a business case that is not justified using millions of dollars of untested technologies, they risk significant failure. And when those SOA projects fail to deliver as promised, do they blame their own efforts, the products they used, or their methods? Of course not. They rest the blame on SOA itself."As far as the authors are concerned:
"On the flip side, well-scoped SOA projects are often remarkably successful. Most case studies of SOA success relate to organizations fixating on a particular business problem, perhaps at even the departmental level, and solving that in a Service-oriented way. The champions of SOA know full well that success comes from focusing the solution on a particular problem and solving it well."
The article goes on to make the case for Enterprise Architecture Teams as the best way to apply SOA principles, because very few individuals have the skills to understand the business combined with the technical acumen necessary to understand how SOA best practices can drive business solutions. Building cross-functional teams that include, for example, line of business representatives, application development, data modeling, process modeling, security, and network operations roles, can be a key element in the success of SOA deployments.
There's also a strong educational requirement needed throughout organizations:
"Where business can see a solution, sometimes IT is blind. Too many times IT departments try to use the SOA hammer to approach every problem as a nail. Indeed, the symptom of ill-scoped SOA projects is partially caused by this inability (or inexperience) to utilize SOA properly. ... Technologists often get stuck in defensive positions regarding particular technological approaches (REST vs. Web Services anyone?). These arguments relate little, if at all, to the business problem at hand and tend to devolve into pedantic arguments of semantics. The truth of the matter is that any technology approach that can solve a business problem is valid, and probably will be displaced in favor of a better one in a few years anyways."
However, the article finishes with some sound advice for those looking to deploy applications based on SOA principles or wondering whether they have the right skills in place to continue with existing deployments:
"Smart architects and business managers who seek to apply SOA to solve their problems should have a firm grasp as to when SOA will provide success and when it is being inappropriately shoe-horned. Such a grasp includes realistic assessments of the people, technologies, processes, and methods of the existing environment and proposed solution, and the drawbacks of any potential solution. Having such a balanced approach serves to further the likelihood of success with SOA, and doesn’t by any means kill the value of SOA itself."
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
No comments
Watch Thread Reply