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 Boris Lublinsky on Mar 10, 2010
According to a new MITRE whitepaper by Larry Pizette, Salim Semy, Geoffrey Raines & Steve Foote, the following are the best practices for successful SOA implementations:
While SOA can provide the benefits of reuse, agility, and loose coupling, these benefits are not always the software architect’s first priorities.For real-time systems or distributed systems with constrained networks, for example, SOA might not be an appropriate architecture paradigm.
Organizations will see the benefits of shared services, business agility, and simplified integration if their SOA adoption strategies are motivated by, and aligned to, resolving business problems.The authors give a series of industry examples of SOA implementations with well defined business goals.
By focusing on business process steps that are used across the enterprise, the reuse of services becomes a natural outcome of the architecture... It is imperative that services be specified at the right level of the business process (i.e., the breadth of functionality provided by the service) so they can easily be mapped to business process steps.An important service feature, according to the authors, is loose coupling, providing certain flexibility for changing the service’s implementation. Finally, the whitepaper talks about formalizing service contracts and making services visible, typically using service registry.
Implementing an SOA by itself does not solve data problems. While SOA makes data more accessible, it might still be unusable due to data quality, availability, and differences in community vocabularies... Insufficient attention to data may compromise the value achieved from an SOA implementation.According to the authors, successfully incorporating data in SOA implementation requires definition of data semantics, ensuring consistent meaning of data exchange between service consumers and providers; data quality - eliminating redundant, inconsistent, or stale data and data availability... providing distributed data services over a network that supports a heterogeneous, and perhaps unpredictable, set of service consumers.
...architects often seek to make their initial SOA adoption an enterprise-wide effort, even when it is not justified by a business case... With SOA, it is best to start small, learn, and then evolve. An incremental approach allows lessons learned to be collected before adopting an SOA in a large way; it minimizes business risks and allows returns to be realized incrementally. However, when scoping SOA efforts, it is important to address a meaningful business problem, focus on piloting the architecture, clearly state the desired outcome and measures of success, and capture lessons learned, which can be leveraged in future efforts.Based on the industry studies, the whitepaper’s authors, suggest to pilot SOA first, addressing specific business problem and defining clear business and architectural success criteria. They also recommend capturing lessons learned and educate the rest of the enterprise before continuing with the next SOA project.
Building an SOA for today can result in tightly coupling services for specific service consumers, resulting in stovepipes with pair-wise connectivity between systems. Furthermore, without planning for future or unpredictable usage, SOA may fail to meet future service demands. Therefore, SOA implementations should be designed with the expectation that requirements will evolve. SOA should be built to allow for scalability and expansion, both in the scope and requirements of the SOA deployment.The main steps ensuring a long-terms vision, according to the authors, include service management (through monitoring), providing information of how well management goals are being met and aid in pinpointing and resolving problems; ensuring scalability of services implementation... including infrastructure, enabling services interaction, scalable development and testing practices; building appropriate security infrastructure, etc.
Successfully implementing the changes necessary for enterprise-wide SOA adoption requires putting policies and processes in place, which are largely driven by business needs. Organizational commitment to governance is necessary for SOA initiatives to be successful.The main faucets of governance described in the whitepaper include architecture - setting up a minimal set of constraints to ensure consistency in service implementations; infrastructure - establishing policies to ensure that an infrastructure platform, which may include messaging, security, and other utility services, is standardized across all projects; information - defining data ownership, establishing policies and guidelines to adhere to data standards chosen by the enterprise, establishing policies to conform to data quality metrics, etc.; portfolio - establishing policies ensuring consistency among service lifecycles, planning business and utility services, and ensuring that the existing enterprise applications are appropriately leveraged when developing services.
...while cost savings is a primary motivation for adopting an SOA... a fundamental challenge to SOA adoption is determining how to pay for the SOA, given steep learning curves, a lack of technology skills and familiarity, a lack of mature industry standards, and a lack of user enterprise management ability (i.e., governance) to plan integrative SOA implementations. An organization adopting SOA approaches needs to have a realistic expectation on how much investment is needed and the expected ROI.They emphasize that initial SOA implementation will nearly always be more expensive compared to traditional applications-based implementations and the actual cost savings might not be realized by every part of the enterprise. In their opinion, most of the cost savings are long term and will come from the organizational agility that the SOA will provide and the ability to share information. Additionally service reuse will lead to reduced maintenance costs.
Although the white paper is fairly high-level it manages to emphasize the majority of important SOA concerns. It can be used as a good introduction for people that are considering an SOA implementation or as a reminder to SOA implementers that it is not only about cool technologies, but also about architecture, business and ROI.
Is whitepaper for members only?
*MITRE whitepaper* link at the very beginning of the article is a public link.
while opening file "enter password to unlock" appear.
I'm not seeing this issue when I download it - I just pulled it down and opened it without issue, and I even see something in the top left corner of the first page which says
"Approved for public release; distribution unlimited". What's your platform and PDF reader?
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.
4 comments
Watch Thread Reply