Enterprise computer systems don't get coffee breaks. They must be continually available and dependable to prevent failures and resulting losses in revenue and customer satisfaction, said David Lounsbury, CTO and vice president of services at the Open Group. To help enterprise architects build dependable open systems and assure customers of their products' reliability, his standards group created the Dependability through Assuredness (O-DA) framework.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Ensuring dependability of complex computer systems is difficult, because they are changed constantly to meet new business service objectives, regulations, customers' requirements and competitors' technological advances, Lounsbury said in an interview at The Open Group Open Platform 3.0 Forum in San Francisco. In this Q&A, he expounds on the market forces that drove the creation of O-DA, first steps in using the standard and why The Open Group's Japanese members drove this standards effort.
Why did Open Group create a standard for open system dependability and assurance?
David Lounsbury: The Open Group's overarching vision is boundary-less information flow, which means lowering the barriers to exchanging any type of data. Until recently, interoperability has been the main focus in extending information flow; but more and more enterprise architects now have to master other qualities of the information exchange: dependability, security, etc. You've got be able to have to know the data is itself is trustworthy, that nobody's tampered with it as it's in progress. You need to know that it may be secure, because you don't want that information disclosed.
Isn't it extraordinary how widely information is distributed today? Talk about boundary-less!
Lounsbury: Yes. Once, information only needed to flow between the departments inside a company, but now it goes far beyond the enterprise … to partners, suppliers, customers and on and on. But that information is only valuable to the extent that you can rely on it.
This situation is like when President Kennedy said the U.S. was going to put a man on the moon by the end of the decade, and "return him safely." Today, enterprise architects must create dependable systems for managing the safety, quality and reliability of information as it goes out into the world and comes back again.
The lowering of boundaries to sending information speedily seems like an opportunity and a curse for enterprise architects.
Lounsbury: Users expect information to be in the right place at the right time. Today, the right answer too late is the wrong answer.
Speed also makes information exchange risky. In the business world, that information exchange has value. If the system is down or whatever, or unavailable, users can quickly get that information from a competitor. So, dependability means less lost revenue. That's why we created O-DA and are coming up with methodologies for designing for continual operation. The desired result is that users know that your business's information is going to be there so they can produce the right result at the right time.
Has the meaning of systems dependability changed over the years?
Lounsbury: Dependability standards have always been focused on closed-box systems, such as embedded systems. Now, we live in an open system's world, where -- most of the time -- nobody owns the whole end-to-end system. The big question now is: How do we architect and operate open systems so they have this quality of dependability?
What are the problems that come from a lack of dependability standardization?
Lounsbury: The Open Group's Japanese membership was in the front of O-DA standards development because they focus mostly on industrial manufacturing and industrial products, especially cars. One motivating factor was that systems in cars are becoming increasingly complex. Few people know that the number of lines of code in your car is going up exponentially. The automakers recognize, and their software architects must create sophisticated tools that are assured to work.
With automation in cars, planes, health care and elsewhere, dependability can be a life or death issue, but there are mundane uses that must be reliable, too. Airplanes have cabin service centers, for example. We're seeing automation everywhere in our lives. [The transportation] system is one that's affecting us all; but outages in any service provider -- banks, cable TVs, etc. -- do, too.
These applications sound like ones living in embedded systems.
Lounsbury: I'll push back on that a little bit. If it's an embedded system, it's a black box. It's got a fixed input and a fixed output. At the open dependability assurance level, the expectation is that different people own different parts of the systems, and different people control different parts of the system. So it is not a closed-box system. [The O-DA framework] is designed to build the case for dependability in a system where people are going to be changing out the components.
What's your advice to companies that are looking at O-DA and might want to try it?
Lounsbury: The first step is determining the business need. Figure out whether your enterprise is changing in a way such that you need to address the pain point of dependability. For example, is the company losing money because a system is down too much?
Next, look at the [O-DA framework], and you'll see references to its underlying dependability standards. A good first step is seeing how the O-DA methodology maps to what you're already doing.
The Open Group is building out more practical guidance for how that's going to happen, [mostly in] seminars.