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.