Roger Sessions: World-Renowned, World's Foremost Expert in High-End Distributed Software Architectures

This week, Stephen Ibaraki, ISP, has an exclusive interview with Roger Sessions, the world's foremost expert in high-end distributed software architectures and the originator of The Software Fortress Model (SFM) for Service-Oriented Architectures.

Roger is a widely sought consultant, celebrated conference and keynote speaker who has influenced tens of thousands of senior and prominent IT leaders and professionals in more than 20 countries. He is the author of six best-selling books (including “Software Fortresses; Modeling Enterprise Architectures”), dozens of papers and featured magazine articles, as well as his own ObjectWatch Newsletter which is nearly 10 years in publication. Moreover, he is the founder of the Architect Technology Advisory which is specifically written for technology leaders who need to understand what is happening in the software architecture space.

Thousands of the leading software architects and senior IT managers worldwide depend on ObjectWatch's Architect Technology Advisory (ATA) and The ObjectWatch Quarterly Newsletter to explain new trends, approaches, technologies, and standards related to enterprise software development in a concise, easy-to-read format.

Amongst his many strategic achievements, Roger is the founder (in 1994) and CEO of ObjectWatch Inc; Board Director of the International Association of Software Architects; Enterprise Interoperability partner with Microsoft, and Microsoft Most Valuable Professional.

Roger’s remarkable prior history includes his studies at Bard College in biology; working as a research scientist at the US National Institute for Health; a stint as a VisiCalc developer at Software Arts; developing software for Prime Computer; then onto IBM and CORBA. 

From 1990-1995, Roger Sessions worked at IBM involved in the CORBA effort. He spent a year as a lead architect for the CORBA persistence service and four years as one of the lead architects for the IBM implementation of CORBA's persistence technologies. Roger Sessions left IBM in 1995 to start ObjectWatch, Inc.; a company dedicated to offering training and consulting services in the field of high scalability, component architectures. He started out focusing on the CORBA technologies, but then turned his attention to Microsoft's distributed technologies, including Java, COM, DCOM, MTS, MSCS, and MSMQ.

His earlier books include: “COM+ and the Battle for the Middle Tier”, “COM and DCOM; Microsoft’s Vision for Distributed Objects”, “Reusable Data Structures for C”, “Class Construction in C and C++”, and “Object Persistence: Beyond Object-Oriented Databases.”

Recent articles include: “Fuzzy Boundaries: Objects, Components, and Services” in ACM Queue Magazine; “Transaction Boundary Management” in Software Magazine V 20 #3; “COMWare Drama: Where Components and TPMs Meet” in Software Magazine V 20 #1; “Tech-Ed 2005: The Elephant That Wasn’t There” in The ObjectWatch Quarterly Newsletter #50; “The Rings of the Enterprise” in newsletter #49; “Web Services: The SCRAM Generation” in newsletter #48; “What is A Service-Oriented Architecture?” in newsletter #45; “Predicting Enterprise Costs” in newsletter #43; “Sharing Data in a Service-Oriented World” in the April 05 Architect Technology Advisory (ATA); “Service Oriented Architecture—Fast Track” in the March 05 ATA .

For more information about ObjectWatch and Roger Sessions, go to:

http://www.objectwatch.com/about_us.htm

Discussion:

Q: Roger, your influence as an internationally-renowned authority is continuing to make its mark on enterprises and IT leaders worldwide. Considering your heavy workload, we appreciate you taking the time to do this interview. Thank you!

A:  Thank you for the opportunity.

Q: Can you tell the audience more about the Architect Technology Advisory (ATA): history, purpose, audience, levels, its future, growth rate?

A:

I started writing the ATA about a year ago. The original idea came from my experiences observing failed large enterprise systems. I noticed how often the root cause of a large, expensive failure is a single flawed design decision, made very early on in the development process. These flawed design decisions, once implemented, are very difficult to back-out. I felt that there was a need for a publication that was directed at architects and focused on helping them make good design decisions, especially on leading-edge technology areas, such as SOAs.

I decided to focus the ATA at critical early design decisions (CEDDs); those decisions that are made early on in a project and have large impacts.

Marketing could have been a problem. However over the years I have built up a loyal following of the ObjectWatch Newsletter, with over 11,000 subscribers. These readers trust me to give unbiased information in a readable format. I hoped that many of these readers would want to try the ATA, and I have been delighted with the results.

We have found that there is not a single ATA formula that fits all customers. Some just need a single architect to read the publication. Others have groups of architects that can benefit from the ATA. Some can also benefit from face-to-face discussions with me. Yet others need ongoing architectural consultation. So we offer a variety of plans to meet different needs. All focus on reasonable cost, high value.

Overall, we have found that the combination of CEDD focus, high value, reasonable cost and trusted information source has been a winning business plan.

Q: Please share specific predictions from your ATAs ranked as “serious” and “very serious” and overview your CAPS (critical action plans).

A:

1) Prediction 1 and AL (alert level):

First, let me explain how my predictions work. In most issues of the ATA, I will make a specific prediction. In order for a specific architect, say "Anne", to understand the seriousness of this prediction, she needs to know both the probability that a given prediction will come true, and the impact on her if that prediction does come true.

To help her, we assign alert levels to predictions ranging from very serious to ignore. (I won’t bore you with the mathematics that we use to calculate alert levels; and refer those interested in this to the ObjectWatch web site.)

Anytime we rate the alert level for a given prediction as either serious or very serious, we also issue a Critical Action Plan (CAP). The CAP gives "Anne" specific advice on how she should deal with the prediction.

Okay. With that background, here is an example of a typical prediction. I’ll start by giving an example of a technical prediction.

In the December 2004 ATA I predicted that “By 2007, HTTPS will no longer be the standard mechanism for implementing SOAP security. It will be replaced by WS-Security.” I rated this prediction serious, because I had a high confidence in this prediction (.90) and I said the impact would be felt over 25% of a typical project’s code.

As part of this prediction, I explained why HTTPS was a poor security model for today’s SOAP systems and why it wouldn’t work at all in the next generation of SOAP. Unfortunately, HTTPS is all that exists today, so it is no wonder that so many systems are building in an HTTPS dependency.

The CAP for this prediction was to eliminate Kerberos and build a layer that would use PKI as a security layer, and to build that layer in such a way as to be replaced once WS-Security is available. (The actual ATA went into much more detail, but this gives you the idea.)

Those that followed my recommendation built systems that are well positioned to take advantage of the new Web Service standards. Those that didn’t, built systems that will be obsolete in another year.

2) Prediction 2 and AL:

In a similar vein, in the November 2004 ATA, I noted that most SOAs were being built around the synchronous messaging model. There is a good reason for the focus on synchronicity, since it is the only messaging model supported today. However, I pointed out that architectures that assumed synchronicity, as most do, will no longer work with the next generation of Web Services. I rated this prediction as serious, since it would negatively impact so much of the code of a typical project. In the CAP, I described how to create an architecture that, while nominally synchronous, was well positioned to take advantage of asynchronous messaging systems, once they became the norm in the 2007 timeframe.

Those that heeded my advice built systems that could continue working through 2010. Those that didn’t, built systems that will need to be substantially rewritten within the next two years.

3) Prediction 3 and AL:

Not all of my predictions are technical in nature. In my May 2005 ATA, I predicted that any given company faces a 40% probability of failure of newly developed SOA systems, not because of technical reasons, but because of communication failures between the technical and business side of the organization. I further predicted that these failures would be total and catastrophic in nature. The significant likelihood of catastrophic failure gave a combined alert level of very serious.

The recommended CAP was to develop a culture in which the business and technical folks share a common language and understanding of web services and business strategy. That particular ATA laid out a step by step path for starting that communication and gave an overview of SOAs from the perspective of the business side of the organization.

Those that followed my recommendations are well positioned to rebuild their business around Web Services. Those that didn’t will continue building systems that are ultimately unsuited to their business needs.

Q: What do you foresee in the future and what are their consequences to businesses and IT leaders/professionals?

One of the areas I am examining closely is workflow. Automated workflow engines (AWE), such as Microsoft’s BizTalk or TIBCO’s product line, are becoming increasingly important in IT. I include in this area Business Process Management (BPM), Business Rules Engines (BRE), and Enterprise Application Integration (EAI).

There are a number of architectural challenges that AWE will introduce. One is the relationship between AWE and Service-Oriented Architectures (SOAs). Although most AWEs are embracing Web Service standards,  I see an impedance mismatch between the applications most organizations develop for SOAs and those that are needed for automated workflow. Because of this, few organizations will find that their SOA endeavors will migrate to AWE, unless those SOA applications were developed with an understanding of the specialized needs of AWE. This will be one area I will be looking at in future ATAs.

A second area that will impact software systems is regulatory requirements. Regulatory requirements, such as Sarbanes-Oxeley, will have a tremendous impact on software architectures, starting in the 2006 timeframe. Software built without an understanding of these requirements will cause substantial problems for organizations down the road. So, as you can imagine, I will be following this carefully in ATAs.

A third area is profitability. For most commercial ventures, profit margins are razor thin. IT is one of the largest cost centers and also one of the major opportunities to improve profitability. This sets up a conflict that must be managed carefully. Organizations must continue to invest in IT, but must do so very carefully.

Q: From your past leadership with CORBA, you learned about standards such as those focusing on portability that fail and those in line with interoperability that succeed. How do these experiences link with your work with SFM (The Software Fortress Model)? Can you overview the 7 key artifacts of SFM and your 6 interactive project stages?

A: The Software Fortress Model is an approach to building systems for interoperability. We have Web service standards that tell us how heterogeneous platforms will interoperate. But these standards tell us nothing about how we should design and implement the applications that will run on those platforms. This is the areas of focus for the Software Fortress Model. It hones in on one specific area of enterprise applications, how those applications will interoperate with each other.

The SFM views applications as living inside software fortresses. The SFM says nothing, (or at least, very little), about how the applications themselves are architected. The SFM is all about the space between applications.

As you mentioned, there are 7 key artifacts of the SFM. There are:

• Walls – Walls prevent any communications to or from the autonomous application inside the fortress, except through approved channels.
• Incoming Drawbridge – The incoming drawbridge is the approved channel for communications coming from the outside world.
• Guards – Guards are the security force that inspect and pass messages coming in from the incoming drawbridge.
• Outgoing Drawbridge – The outgoing drawbridge is the approved channel for communications going to the outside world.
• Envoys – Envoys are the intermediaries between the application and the outgoing drawbridge.
• Workers – The workers do the work of the Software Fortress. They are the application inside.
• Data store – Workers, or applications need to store the implementation and reference data someplace, and the data store is a generic description of where this data will go. 

Q: Please share three case studies that illustrate your ideas and work.

A Case 1: A large bank is using the SFM to define how their autonomous financial applications work together. They are particularly interested in the security aspects of the SFM because they focus so much on ensuring that unauthorized systems usages are not possible.

Case 2: A retail organization is using the SFM to define relationships between the point-of-sales systems, the inventory systems, the regional centers, and the purchasing systems. 

Case 3: A non-profit organization is using the SFM to help them build workflow systems to manage caseworkers, recipients, and donors.

Q: What are your five most significant articles; overview them; for what reasons are they significant; why should businesses and IT professionals care?

A:  I have written a lot of articles, so let me think...

1) One of my first important articles was titled, “Matters of State”. In this article, I used a comparison between the tables at Starbucks and the offices at IBM as an analogy to stateless systems (Starbucks) and statefull systems (IBM offices). I showed why stateless systems are so much more efficient than their statefull counterparts. This concept is key to understanding the basic principles of scalability in multi-tier software systems. This article appeared in the July, 1998 issue of The ObjectWatch Newsletter. (For information about The ObjectWatch Newsletter, see http://www.objectwatch.com)

2) In June of 1999 of the ObjectWatch Newsletter, I wrote a five part article titled, “A Critical Look at EJB 1.1”. In this article I explained why the architecture of Enterprise Java Beans was fatally flawed, and why systems using that architecture were doomed to failure. Back then, criticizing EJB was like criticizing motherhood! Those readers who took what I said to heart have saved themselves untold pain and misery. Those that insisted I was wrong continued to build systems that eventually failed. Now my criticisms have been proven and EJB has been largely discredited.

3) In the December 1999 issue of The ObjectWatch Newsletter, I wrote an important article titled, “Why I Don’t Drive a Lamborghini”. This article laid out the reasons that enterprise architectures built on low-end clusters are much better than enterprise architectures built on expensive, high-end machines. These ideas are also now widely accepted.

4) In the October 2004 issue of ACM’s Queue, I wrote an article titled, “Fuzzy Boundaries: Objects, Components, and Services” in which I explained why so many enterprise systems fail when architects and developers don’t understand the fundamental differences between objects, components, and Web services.

5) In the November 2004 Architect Technology Advisory I wrote about how the coming shift in communications from synchronous to asynchronous protocols is going to catch many organizations off guard and with software systems that will be poorly matched with the next generation of Web service technologies. (Information about the ATA is available at www.objectwatch.com)

Q: What do you foresee as the major competing technologies in the enterprise space in three years; what are their strengths and weaknesses? Who will be the big losers? How should businesses prepare for these changes?

A: The major competition over the next three years is going to be in the areas of interoperability and workflow automation.

These are two related topics. Interoperability defines how systems work together and workflow automation describes how you automate that flow of work. Both of these areas will be highly influenced by the Web service standards, which are in a state of flux today.

The big losers in this area unfortunately are going to be large organizations, such as banks and insurance companies), that are building systems today that will not be functional once these new standards come on line. Businesses must prepare for this by architecting for change. The articles in my Architect Technology Advisory are focused on this idea, architecting for change. So of course my strongest recommendation is that businesses prepare by reading the Architect Technology Advisory. But however businesses do so, they must find ways to understand what technology changes are coming down the road and learn how to build their systems to withstand that change. The stakes are enormous.

To give you just one example, most companies are dealing with Web Service security in one of three ways. The first is by ignoring it. The second is by using HTTPS as an underlying protocol. The other is by building ad-hoc security systems. All of these approaches are fatally flawed. There are ways to build highly secure Web services today that will be able to withstand the coming changes in the area of Security, but neither HTTPS nor an ad-hoc (nor, or course, the head-in-sand) approach is it. 

Q: Can you overview your next book including describing your intended audience and why should they read it?

A: At the moment, I am focusing most of my writing activity on the Architect Technology Advisory, a monthly subscription service. The problem with books is their lag time which makes it difficult to deal with issues of immediate concern. My main interest right now is helping organizations build functional and long-lasting software systems. The ATA seems to be a better tool for this.

The audience for the ATA are enterprise architects and IT management. They should read it because they are responsible for building large, expensive, mission-critical systems. My articles tell them how to do this better, what issues they need to be aware of, and what changes are likely to impact them over the next few years.

Q: Do you see still Open Source as IBM’s dream come true? How do you track its evolution since we last talked and its future?

A: IBM makes most of its money in two ways. One is by selling expensive hardware. The other is by selling expensive consulting services. You couldn’t ask for a better support system for this business plan than Open Source.

Q: What kinds of disruptive innovations are on the horizon? What are their implications: to business, IT professionals, others?

A: The next generation of Web Services will be highly disruptive. It will shift the focus entirely from SOAP messages to SOAP infrastructures. The implications of this will be that many current Web Services will no longer work as these new SOAP infrastructures come on line. Many new Web Services will also fail, because the new paradigm will be so unfamiliar to most people.

The next generation of automated workflow, (which will be impacted by Web services), will also be disruptive. Most people today are building Web Services that are too coarse grained to play well in the next generation of automated workflow.

As automated workflow becomes a more important strategy in the workplace, there will be increasing tensions between our understanding of how to build good Web Services and our understanding of how to build good Workflow participants. We are only just beginning to understand how to reconcile this coming clash.

Q: What do you foresee for China and India; for what reasons?

A: Both countries can benefit from the move toward building autonomous interoperating systems. Such systems are readily farmed out to off-shore organizations, and, of course, both China and India are good candidates.

In the short term, India will benefit more because of their widespread usage of English which makes communications with us, language-challenged anglophiles, so much easier.

In addition to the language issue, China also faces a handicap in its generally poor record of taking intellectual property rights seriously.

So for the short term, I see India as the bigger winner of the two. Long term, China could address its shortcomings and also become a strong contender. Other countries that are also well positioned to benefit are Mexico, Singapore, and Malaysia.

Unlike some, I don’t see the globalization of software development as a bad thing. It certainly introduces stress, as does all change. But history does not favor companies that artificially inflate cost. And, in any case, I see globalization as benefiting the human race. Far better that we compete with each other than we fight with each other!

Q: You have never been one to avoid controversy, so now choose any five topics of your choosing and provide commentary.

A: An open-ended opportunity for five rants... Let’s see... where shall I begin...

- Databases are poorly designed for today’s needs. They are focusing on issues that are rapidly becoming irrelevant. Nobody needs a database anymore that can support millions of concurrent users with billions of transactions per minute of throughput. We need databases that focus more on serving small numbers of users very reliably and very inexpensively. We need databases that have good support for XML data. We need databases that are effectively extensions of a Web Service-enabled operating system.

- Open source is based on a faulty financial model: that one can save money by using free tools. Anybody who thinks this is true should spend a day trying to pound in nails with a rock.

- The Web Service Standards groups are out of control. They should be focusing more on getting the basics to work. BPEL and WS-Transactions (both courtesy of Microsoft and IBM) are examples of standards that we shouldn’t be wasting time on. There should be a law passed that no new Web Service Standards can be created until they can get the ones we have now to work.

- Linux will soon go the way of Unix: fragmented into a series of different operating systems, each controlled by different groups, each incompatible with the other. The idea of a free operating system will also soon disappear, as people realize they are spending more money on support than they use to spend on the operating system.

- The morning doves are eating all of our bird food and scaring the cardinals away. Somebody should do something about them.

Q: Roger, it is always a real pleasure and delight to speak with you. You have changed the world and will continue to do so. Thank you for sharing your unbounded wisdom and experiences with our audience. Here is a spin on a question I asked before, “What would you do differently?” 

A: I just moved from the Big City (Austin, Texas) to a tiny, itsy bitsy, droplet of a town (Chappell Hill, Texas). When you drive through downtown (both blocks of it), you need to stop and shoo the chickens out of the way. I have traded Starbucks in the day for stars at night. Traffic sounds for the sound of coyotes howling. Suburban lawns for country pastures. Should have done it ten years ago. Gotta go now. The sun is setting, and it’s going to be a good one.