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 Srini Penchikala on May 26, 2009
Evaluating software architecture is an important part of enterprise architecture (EA). Felix Bachmann of Software Engineering Institute (SEI) recently talked about how to effectively evaluate software architecture and identify risks in enterprise applications. He hosted a seminar at SEI Architecture (SATURN) conference on architecture evaluation principles. He also discussed how SEI's Architecture Tradeoff Analysis Method (ATAM) framework utilizes these principles to help with the architecture evaluation efforts.
Felix talked about three categories to group the principles of architecture evaluation, "The Measure", "Understanding of the Architecture", and "The Know How". The measure part of the software architecture evaluation includes eliciting the organizational needs from the stakeholders and translating them into quality attribute requirements in a precise and measurable way. He talked about four principles in this category.
It's also important to understand the approaches the architect used, understand the functional distribution and understand where to find the trouble spots. There are three principles in understanding the architecture.
The "Know How" part of software architecture evaluation includes:
Using an architecture evaluation method that adheres to all the principles can almost guarantee successful results. Felix indicated that an architecture evaluation method that does not use any of the principles will very likely end in a disaster. He suggested that these principles should be applied based on the context because the adherence to some principles is more important than to others. The better a method utilizes the principles, the higher the chances for success.
The ATAM framework utilizes these principles in architecture evaluation. The main part of the ATAM consists of nine steps separated into four groups:
Following are the steps in the ATAM evaluation process.
Felix concluded the discussion by saying that the software architects should carefully watch the results of the architecture evaluation to continuously improve the evaluation process.
Srini Penchikala currently works as Security Architect and has 17 yrs of experience in software product management.
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