Transcript of a podcast on security as architectural best practices, recorded at the first Security Practitioners Conference at The Open Group's 21st Enterprise Architecture Conference in San Diego, February 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group's first Security Practitioners Conference in San Diego, the week of Feb. 2, 2009.
Our topic for this podcast, part of a series of events and coverage at this conference, centers on enterprise security and the intersection with enterprise architecture (EA). The goal is to bring a security understanding across more planning- and architectural-level activities, to make security pervasive -- and certainly not an afterthought.
The issue of security has become more important over time. As enterprises engage in more complex activities, particularly with a boundaryless environment -- which The Open Group upholds and tries to support in terms of management and planning -- security again becomes a paramount issue.
To help us understand more about security in the context of enterprise architecture, we're joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Let's start with you, Jim. Security now intersects with more elements of what information technology (IT) does, and there are more people responsible for it. From the perspective of The Open Group, why has it been a transition or a progression in terms of bringing security into architecture? Why wasn't it always part of architecture?
Jim Hietala: That's a good question, but probably predates my involvement with The Open Group. In TOGAF 9, the latest iteration of TOGAF that we announced this week, there is a whole chapter devoted to security, trying to get to the idea of building it in upfront, as opposed to tacking it on after the fact.
You've seen movement, certainly within The Open Group, in terms of TOGAF, and our enterprise architecture groups try to make that happen. It's a constant struggle that we've had in security -- the idea that functionality precedes security, and security has to be tacked on after the fact. We end up where we are today with the kind of security threats and environment that we have.
Gardner: Chenxi, we've seen security officer emerge as a role in the past several years. Shouldn't everyone have, in a sense, the role of security officer as part of their job description?
Chenxi Wang: Everyone in the organization or every organization? My view is slightly different. I think that in the architecture group there should be somebody who is versed in security, and the security side of the house should have an active involvement in architecture design, which is what we are seeing as an emerging trend in a lot of organizations today.
Gardner: We're also facing a substantial economic downturn globally. Often, this accelerates issues around risk, change management, large numbers of people entering and leaving organizations, mergers and acquisitions, and provisioning of people off of applications and systems.
Kristin, perhaps you can give us a sense of why security might be more important in a downturn than when we were in a boom cycle?
New technologies
Kristin Lovejoy: There are a couple of things to think about. First of all, in a down economy, like we have today, a lot of organizations are adopting new technologies, such as Web 2.0, service-oriented architecture (SOA) style applications, and virtualization.
Why are they doing it? They are doing it because of the economy of scale that you can get from those technologies. The problem is that these new technologies don't necessarily have the same security constructs built in.
Take Web 2.0 and SOA-style composite applications, for example. The problem with composite applications is that, as we're building these composite applications, we don't know the source of the widget. We don't know whether these applications have been built with good secured design. In the long-term, that becomes problematic for the organizations that use them.
It's the same with virtualization. There hasn't been a lot of thought put to what it means to secure a virtual system. There are not a lot of best practices out there. There are not a lot of industry standards we can adhere to. The IT general control frameworks don't even point to what you need to do from a virtualization perspective.
In a down economy, it's not simply the fact we have to worry about privileged users and our employees, blah, blah, blah. We also have to worry about these new technologies that we're adapting to become more agile as a business.
Gardner: Nils, how do you view the intersection of what an enterprise architect needs to consider as they are planning and thinking about a more organized approach to IT and bringing security into that process?
Nils Puhlmann: Enterprise architecture is the cornerstone of making security simpler and therefore more effective. The more you can plan, simplify structures, and build in security from the get-go, the more bang you get for the buck.
It's just like building a house. If you don't think about security, you have to add it later, and that will be very expensive. If it's part of the original design, then the things you need to do to secure it at the end will be very minimal. Plus, any changes down the road will also be easier from a security point of view, because you built for it, designed for it, and most important, you're aware of what you have.
Most large enterprises today struggle even to know what architecture they have. In many cases, they don't even know what they have. The trend we see here with architecture and security moving closer together is a trend we have seen in software development as well. It was always an afterthought, and eventually somebody made a calculation and said, "This is really expensive, and we need to build it in."
Things like security and the software development lifecycle came up, and we are doing this now for architecture. Hopefully, we'll eventually do this for complex systems. Kristin mentioned Web 2.0. It's the same thing there. We have wonderful applications, and companies are moving towards Facebook en masse, but it's a small company. The question is, was security built in, has anyone vetted that, or are we not just repeating the same mistake we did so many times before?
A matter of process
Gardner: We see with security that it's not so much an issue of technology but really about process, follow through, policy determination and enforcement, and the means to do that.
Chenxi, when it comes to bringing security into a regulated provision, policy-driven process, it starts to sound like SOA. You'd have a repository, you'd have governance, and the ways in which services would be used or managed and policies applied to them. Is there actually an intersection between some of the concepts of architecture, SOA, and this larger strategic approach to security?
Wang: There is definitely some intersection. If you look at classic SOA architecture, there is a certain interface, and you can specify what the API is like. If you think about a virtual approach to security, it's also a set of policies you need to specify upfront, hopefully, and then a set of procedures in which you adhere to these policies.
It's very much like understanding the API and the parameters that go into using these APIs. I hadn't actually thought about this really nicely laid out analogy, Dana, but I think that's a quite good one.
Gardner: I think we're talking about lifecycles and managing lifecycles and services. I keep seeing more solutions, shared services, and then actual business and IT services, all being managed in a similar way nowadays with repository and architecture.
Jim, this is your first security conference at The Open Group. It's also coinciding with a cloud computing conference. Is there an element now, with the "boundarylessness" of organizations and what your architectures have tried to provide in terms of managing those permeable boundaries and this added layer, or a model for the cloud? More succinctly, how do the cloud and security come together?
Hietala: That's one of the things we hope to figure out this week. There's a whole set of security issues related to cloud computing -- things like compliance regulation, for example. If you're an organization that is subject to things like the payment card industry data security standard (PCI DSS) or some of the banking regulations in the United States, are there certain applications and certain kinds of data that you will be able to put in a cloud? Maybe. Are there ones that you probably can't put in the cloud today, because you can't get visibility into the control environment that the cloud service provider has? Probably.
There's a whole set of issues related to security compliance and risk management that have to do with cloud services. The session this week with a number of cloud service providers, we think, will bring a lot of those questions to the surface.
Gardner: Clearly, those on the naysaying side of the cloud argument often have a problem with the data leaving their premises. As we've heard from other speakers at the conference, having data or transactions that are separate from your organization or that happen at someone else's data center is actually quite common, and is sort of a cultural shift in thinking.
Nils, what do you think needs to happen from this cultural perspective in order for people to feel secure about using cloud models?
A shift in thinking
Puhlmann: We need to shift the way we think about cloud computing. There is a lot of fear out there. It reminds me of 10 years back, when we talked about remote access into companies, VPN, and things like that. People were very fearful and said, "No way. We won't allow this." Now is the time for us to think about cloud computing. If it's done right and by a provider doing all the right things around security, would it be better or worse than it is today?
I'd argue it would be better, because you deal with somebody whose business relies on doing the right thing, versus a lot of processes and a lot of system issues. A lot of corporations today are understaffed, or there is a lot of transition, and a lot of changes there. Simply, things are not in order or not the way they should or could be.
Then, we have the data issue. Let's face it, we already outsource so much work to other places. If ever my data is in a certain place, where I have audited and vetted that provider, or somebody from a remote country as a DBA is accessing my data in-house, is there really a difference when it comes to risk? In my mind, not really, because if you do both well, then it's a good thing.
There's too much fear going into this, and hopefully the security community will have learned from the past and will do a good job in addressing what we don't have today, like best practices, and how vendors and customers strive for that.
Gardner: Kristin, I read a quote recently where someone said that the person or persons that manage the firewall are the most important people in the IT organization. Given what we are dealing with in terms of security, and also trying to bail ourselves of some of these hybrid models, do you agree with that, and if so, why?
Lovejoy: That's a leading question. Is the firewall administrator important? Obviously, yes. More important than ever. In a world with no boundaries, it becomes very hard to suggest that that is accurate.
What we're seeing from a macro perspective is that the IT function within large enterprises is changing. It's undergoing this radical transformation, where the CSO/CISO is becoming a consultant to the business. The CSO/CISO is recognizing, from an operational risk perspective, what could potentially happen to the business, then designing the policies, the processes, and the architectural principles that need to be baked in, pushing them into the operational organization.
From an IT perspective, it's the individuals who are managing the software development release process, the people that are managing the changing configuration management process. Those are the guys that really now hold the keys to the kingdom, so to speak.
Particularly when you are talking about enterprise cloud, they become even more important, because you have to recognize -- and Nils was mentioning this or inferred this -- that cloud provides a vision of simplicity. If you think about cloud and the way it's architected, a cloud could be much simpler than the traditional enterprise. If you think about who's managing that change and managing those systems, it becomes those folks that are key.
Gardner: Why is the cloud simpler? Is it because you're dealing now at a services and API level and you're not concerned necessarily with the rest of the equation?
Lovejoy: That's correct.
Gardner: Is that good for security or bad?
Aligning security and operations
Lovejoy: We've been dancing around the subject, but my hope is that security and operations become much more aligned. It's hard to distinguish today between operations and security. So many of the functions overlap. I'll ask you again, changing configuration management, software development and release, why is that not security? From my perspective, I'd like to see those two functions melding.
Gardner: So, security concerns and approaches and best practices really need to be pervasive throughout IT?
Lovejoy: Exactly. They need to come from the top, they need to move to the bottom, and they need to be risk based.
Gardner: Now, when it comes to the economics behind making security more pervasive, the return on investment (ROI) for security is one of the easier stories. Not being secure is very expensive. Being publicly not secure is even more expensive. Let's go back to Chenxi, the economics of security, isn't this something that people should get easy funding for in an IT organization?
Wang: The economics of security. This issue has been in research for a long time. Ross Anderson, who is a professor at University of Cambridge, runs this economics of security workshop since 1996, or something like that. There is some very interesting research coming out of that workshop, and people have done case studies. But, I'm not sure how much of that has been adopted in practice.
I've yet to find an organization that takes a very extensive economics-based approach to security, but what Kristin said earlier and what you just said is happening. We're seeing the IT security team in many organizations now have a somewhat diminished role, in the sense that some of the traditional security tasks are now moving into IT operations or moving into risk and compliance.
We're even seeing that security teams sometimes have dotted reporting responsibility to the legal team. Some of the functions are moving out of the security team, but at the same time, IT security now has an expanded impact on the entire organization, which is the positive direction.
Gardner: If there is a relationship between doing your architecture well, making systemic security, thought, vision, and implementation part and parcel with how you do IT, then it seems to me that the ROI for security becomes a very strong rationale for good architecture. Would you agree with that, Jim?
Hietala: I would. Organizations want, at all costs, to avoid plowing ahead with architectures, not considering security upfront, and dealing with the consequence of that. You could probably point to some of the recent breaches and draw the conclusion that maybe that's what happened. So, I would agree with that statement.
Gardner: We did have quite a few high profile breaches, and of course, we're seeing a lot more activity in the financial sector. Actually, we could fairly call it a restructuring of the entire financial sector. Do you expect to see more of these high-profile breaches and issues in 2009?
Same song - second verse
Hietala: I'll be interested to hear everyone else's opinion on this as well, but my perspective would be yes. It's been interesting to me that 2009 has started out with what I would call "same song, second verse." We've had a massive worm that propagated through a number of means, but one of which is removable storage media. That takes me back to 1986 or 1988, when viruses propagated through floppy disk.
We've had the Heartland breach, which may be as many as 100 million credit cards exposed. Those kinds of things, unfortunately, are going to be with us for some time.
Gardner: Let's get the perspective of others. Kristin, is this going to be a very bad year for security?
Lovejoy: The more states that pass privacy disclosure requirements that mandate that you actually disclose a breach, the more we're going to hear. Does this mean that there haven't always been breaches? There have always been breaches, but we just haven't been talking about them. They're becoming much more public today.
Do I see a trend, where there are employees terminated or worried employees who are perpetrating harm on the business? The answer is yes. That is becoming a much more of an issue.
The second issue that we're seeing, and this is one of those quasi-security, quasi-operational issues, is that, because of the resource restrictions within organizations today, people are so resource starved, particularly around the changing configuration management process.
We're beginning to see where there are critical outages, particularly in infrastructure systems like those associated with nuclear power and heavy industry, where the folks are making changes outside the change process simply because they are so overloaded. They're not necessarily following policy. They're not necessarily following process.
So, we are seeing outages associated with individuals who are simply doing a job that they are ill-informed to do or overwhelmed and not able to do it effectively.
Gardner: Or perhaps cutting corners as a result of a number of other diminished resources.
Lovejoy: That's exactly right.
Gardner: Nils, do you have any recommendations for how to come into 2009 and not fall into some of these pitfalls, if you are an enterprise and you are looking at your security risk portfolio?
Security part of quality
Puhlmann: Security to me is always a part of quality. When the quality falls down in IT operations, you normally see security issues popping up. We have to realize that the malicious potential and the effort put in by some of the groups behind these recent breaches are going up. It has to do with resources becoming cheaper, with the knowledge being freely available in the market. This is now on a large scale.
In order to keep up with this we need at least minimum best practices. Somebody mentioned earlier, the worm outbreak, which really was enabled by a vulnerability that was quite old. That just points out that a lot of companies are not doing what they could do easily.
I'm not talking about the tip of the iceberg. I'm talking about the middle. As Kristin said, we've got to pay attention to these things and we need to make sure that people are trained and the resources are there at least to keep the minimum security within the company.
Gardner: As we pointed out a little earlier, security isn't necessarily an upfront capital cost. You don't download and install security. It's process and organizational and management centric. It sounds like you simply need a level of discipline, which isn't necessarily expensive, but requires intent.
Puhlmann: Yes, and that is actually similar to architecture. Architecture also is discipline. You need to sit down early and plan, and it's the same for security. A lot of things, a lot of low hanging fruit, you can do without expensive technology. It's policies, process, just assigning responsibility, and also changing security so it's a service of a business.
The business has no interest in either a breach or anything that would negatively affect the outcome of a business, for example, business continuity.
We talked earlier about how IT security might change. My feeling is that security will more and more become a partner of the business and help the business achieve its goals. At some point, nobody will talk about ROI anymore, because it's just something that will be planned in.
Gardner: Jim, what about this issue of intent? Is this something that we can bring into the architectural framework, elevate the need, and focus on intent for security?
Hietala: I believe so. Most system architects are going to be looking at trying to do the right things with respect to security and to ensure that it's thought about upfront, not later on in the cycle.
Gardner: Chenxi, in the market among suppliers that are focused on security, how are they adapting to 2009, which many of us expect to be a difficult year? We mentioned that it's about intent, but there are also products and technologies. Is there any top-of-mind importance from your perspective?
Slight increase in spending
Wang: We haven't seen a severe cut of IT security budget yet from organizations we surveyed, perhaps because some of those budgets were set before the economic downturn happened.
For some of them, we actually saw a slight increase, because just as Lehman Brothers is now Barclays, you have to merge the two IT systems. Now, you have to spend money on merging the two systems, as well as security. So, there is some actually increase in budget due to the economic situation.
A lot of vendors are taking advantages of that, and we are seeing an increased marketing effort on helping to meet security regulations and compliance. Most of us anticipate an increase of regulatory pressure coming down the pipeline, maybe in 2009, maybe in 2010. My belief is that we'll see a little bit more security spending there, because of the increased regulatory pressure.
Gardner: Kristin, we've discussed process and architecture, but are there any particular technologies that you think will be prominent in the coming year or two?
Lovejoy: Interestingly enough, identity and access management (IAM) is likely to be one of the more significant acquisitions that most businesses make.
This goes back to the business value point of security that we have been making, if you think about what's happening in the world with all of these folks wanting to access the network via smart devices. How are they going to do that? Well, they are going to do that using some sort of authentication mechanism that allows them to securely connect back.
Most organizations want to be able to access the new customer, the new consumer, via smart devices. They want to be able to allow their employees access to the network via smart devices or via any kind of other mobile device, which allows them to do things like telecommute.
IAM, as an example, is a technology that enables the business to offer a service to the employee or to that new consumer. What we're seeing is that organizations are purchasing IAM, not necessarily for security, but for the delivery of a secure service. That's one area where we are seeing uplift.
Gardner: Let's just unpack that a little bit. How is this is different from directory provisioning or some of the traditional approaches? These folks wouldn't be in the directories at that point?
Identity managements
Lovejoy: What we're seeing is much more of a focus on federated identity management and single sign-on. In fact, we're beginning to see this trend in our customer base, and a lot of organizations have been talking about this issue of mobile endpoint management. It's very hard in the new world to secure these mobile devices. What organizations are saying to us is, "Why can't we just use single sign-on and federated identity management?"
Single sign-on, in particular, has the capacity, if you think about it in the right way, to uncouple the device from the individual who is using the device, define the policy, apply the policy to the role, and then based on the role, secure the endpoint or isolate the endpoint. It's a very interesting way in which organizations are beginning to think about how they can use this technology as an alternative to traditional secure mobile endpoint management.
Gardner: It also sounds, while pertinent to mobile, that they would have a role in cloud or hybrid boundaryless types of activities.
Lovejoy: That's absolutely correct.
Gardner: Does anyone have anything to offer on this IAM in the cloud.
Puhlmann: Kristin is right. We've tried IAM for many years, and there have been many expensive failed projects in large corporations. Perhaps, we need the cloud to give us this little push to really solve it once and for all in a very federated model. I'd very much like to see that. Based on past experience, though, I'm a little cautious how quickly it will happen.
I think what we will see is a simplification of security, because it has gotten to a point where it's just too complex to handle with too many moving parts, and that makes it hard to work with and also expensive.
Also, we'll see a more realistic approach to security. What really matters? Do we really need to secure everything, or do we need to focus on certain types of data, and where is that really? Do we have to close off every little door, or can we leave some doors open and go closer to where our assets are. How much do they really mean to us?
Gardner: Great. We've been discussing security and some of the pressures of the modern age, this particular economic downturn period, but also in the context of process and architecture.
I want to thank our panelists. We were joined by Chenxi Wang, principal analyst for security and risk management at Forrester Research; Kristin Lovejoy, director of corporate security strategy at IBM; Nils Puhlmann, chief security officer and vice president of risk management of Qualys, and Jim Hietala, vice president of security for The Open Group.
Thanks to you all. Our conversation comes to you through the support of The Open Group, from the first Security Practitioners Conference here in San Diego in February, 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Transcript of a podcast on security as architectural best practices, recorded at the first Security Practitioners Conference at The Open Group's 21st Enterprise Architecture Conference in San Diego, February 2009. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:
The Open Group's CEO Allen Brown interview
Live panel discussion on enterprise architecture trends
Deep dive into TOGAF 9 use benefits
Reporting on the TOGAF 9 launch
Panel discussion on cloud computing and enterprise architecture
Access the conference proceedings
General TOGAF 9 information
Introduction to TOGAF 9 whitepaper
Whitepaper on migrating from TOGAF 8.1.1 to version 9
TOGAF 9 certification information
TOGAF 9 Commercial Licensing program information
Saturday, February 14, 2009
Friday, February 13, 2009
Interview: Guillaume Nodet and Adrian Trenaman on Apache ServiceMix and Role of ESBs in OSS
Transcript of a BriefingsDirect podcast with Guillaume Nodet and Adrian Trenaman of Progress Software on directions and trends in SOA and open source infrastructure.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about open source, service-oriented architecture (SOA) developments, and trends.
We are going to catch up and get a refresher on some important open-source software projects in the Apache Software Foundation. We’ll be looking at the Apache ServiceMix enterprise service bus (ESB), and the toolkit, and we are going to talk with some thought leaders and community development leaders to assess the market for these products, particularly in the context of cloud computing, which is certainly getting a lot of attention these days.
We'll also look at the context around such technologies as OSGi and Java Business Integration (JBI). We want to also think about what this means for enterprise-caliber SOA, particularly leveraging open-source projects. [Access more FUSE Community podcasts.]
To help us sort out and better understand the open-source SOA landscape, we’re joined by Guillaume Nodet, software architect at Progress Software and vice president of Apache ServiceMix at Apache. Welcome to the show, Guillaume.
Guillaume Nodet: Thank you.
Gardner: We are also joined by Adrian Trenaman, distinguished consultant at Progress Software. Hey, Adrian.
Adrian Trenaman: Hey, Dana. How is it going?
Gardner: Good. Now, we are starting to see different patterns of adoption and use-case scenarios around SOA, and open-source projects. Counterpart offerings for certification and support, such as the FUSE offerings from Progress, are getting more traction in interesting ways. The role of ESBs, I think as we can safely say, it is expanding.
The role for management and policy and rules and roles is becoming much more essential, not on a case-by-case basis or tactical basis, but more from a holistic management overview of services and other aspects of IT development and deployment.
First I want to go to Guillaume. Give us a quick update on Apache ServiceMix, and how you see it being used in the market now?
Nodet: Apache ServiceMix is one of the top-level projects at the Apache Software Foundation. It was started back in 2005, and was graduated as a top-level project a year-and-a-half ago. ServiceMix is an open-source ESB and it's really a well-known ESB for several reasons, which we’ll come to later. It's really a full-featured ESB that is widely used in a whole range of companies from government to banking applications. There’s very wide use of ServiceMix.
Gardner: Tell us a little bit about your background, and how you became involved. How long have you been working on ServiceMix, and what led you up to getting involved?
Nodet: Back in 2004, I was working at a small company based in France, and we were looking for an ESB for internal purposes. I began to do some research on the open-source ESBs available at that time. I was involved in the Mule Project and I became a committer in my spare time, and had been one of the main committers for six months.
In the summer of 2005, my company was firing people for economical reasons, and I decided to take a break and leave the company. So I sent an email to James Strachan, who was just starting ServiceMix, and that's how I became involved. I was hired by LogicBlaze at the time, which has been acquired by IONA and now Progress.
Gardner: Tell us a little bit more about the context of the ServiceMix ESB in some of the other Apache Software Foundation projects, just so our listeners understand that this isn't necessarily standalone. It can be used, of course, standalone, but it fits into a bigger picture, when it comes to SOA infrastructure. Maybe you could just explain that landscape as it stands now.
The bigger picture
Nodet: ServiceMix is an ESB and reuses lots of other Apache projects. The main ones which ServiceMix reuse is Apache ActiveMQ which is a message broker so it is for the JMS backbone infrastructure. We also heavily use Apache CXF, which is a SOAP stack that integrates nicely in ServiceMix. One of the other projects that we use is Apache Camel, which is a sub-project of Apache ActiveMQ, is a message router, which is really efficient and it uses DSL to be able to configure routers very easily. So these are the three main projects that we use.
Of course, for ServiceMix 4.0, we are also using the Apache Felix OSGi Framework, and lots of other projects that we use throughout ServiceMix. There are really big ties between ServiceMix and the other projects. Another project that we can leverage in ServiceMix is Apache ODE, which is the business process execution language (BPEL) Engine.
Gardner: Now, it's not always easy to determine the number of implementations, particularly in production, for open-source projects and code. It's a bit easier when you have a commercial vendor. You can track their sales or revenues and you have a sense of what the market is doing.
Do you have any insight into what's been going on, in a larger trend around these SOA open-source projects in terms of implementation volumes? Are we still in test, are people in pilot, or are we seeing a bit more. And, what trends are there around actual production implementation? I'll throw that to either one, Adrian or Guillaume.
Trenaman: I’m happy to chip in there. We’ve seen, quite a lot of work in terms of real-world sales. So you started in ServiceMix, obviously. We have been using ServiceMix for some time with our customers, and we have seen it used and deployed, in anger, if you will. What's interesting for me is the number of different kinds of users out there, the different markets that it gets deployed in. We have had users in airline solutions, in retail, and extensive use in government situations as well.
We recently finished a project in mobile health, where we used ServiceMix to take information from a government health backbone, using HL7 formatted messages, and get that information onto the PDAs of the health-care officials like doctors and nurses. So this is a really, really interesting use case in the healthcare arena, where we’ve got ServiceMix in deployment.
It’s used in a number of cases as well for financial messaging. Recently, I was working with a customer, who hoped to use ServiceMix to route messages between central securities depositories, so they were using SWIFT messages over ServiceMix. We’re getting to see a really nice uptake of new users in new areas, but we also have lots of battle-hardened deployments now in production.
Gardner: One of the nice things about this trend towards adoption is that you often get more contributions back into the project. Maybe it would be good now to understand who is involved with Apache, who is really contributing, and who is filling out the feature sets and defining the requirements around ServiceMix. Guillaume, do you have any thoughts about who is really behind this in terms of the authoring and requirements?
From the community
Nodet: The main thing is that everything comes from the community at large. It’s mainly users asking how they can implement a given use case. Sometimes, we don't have everything set up to fulfill the use case in the easiest way. In such a case, we try to enhance ServiceMix to cover more use cases.
In terms of contributors, we have lots of people working for different companies. Most of them are IT companies who are working and implementing SOA architecture for one of their customers and they are using ServiceMix.
We have a number of individual contractors who do some consulting around ServiceMix and they are contributing back to the software. So, it's really a diverse community. Progress is, obviously, one of the big proponents of Apache ServiceMix. As you have said, we run our business using the FUSE family of projects.
So, it's really a very diverse community and with different people from different origins, from everywhere in the world. We have Italian guys, we have, obviously, US people, and we have a big committee.
Gardner: The JBI specification has been quite central to ServiceMix. If you could, give us an update on what JBI, as its own spec, has been up to, and what that means for ServiceMix, and ultimately FUSE. Furthermore, let's get into some of the OSGi developments. It has really become hot pretty quickly in the market. So what's up with JBI and OSGi?
Nodet: The JBI specification has been out since the beginning of 2005. It defines an architecture to build some ESBs in Java. The main thing is that the key concept is normalized exchanges. This means that you can deploy components on the JBI container, and all of these components will be able to work together without any problems because they share a common knowledge of exchanges, and the messages between components are implemented. This is really a key point.
Anyone can grab a third party component from outside ServiceMix. There are a number of examples of components that exist, and you can grab such a component and deploy it in ServiceMix and it will just work.
That's really one of the main points behind the JBI specification. It’s a Java centric specification. I mean that the implementation has to be done in Java, but ServiceMix allows a lot of different clients from other technologies to jump into the bus and exchange data with other components.
So one of the things that we use for that is a STOMP protocol, which is a text-based messaging protocol. We have lots of different implementations from Ruby, Python, JavaScript and lots of different languages that you can use to talk to the ServiceMix bus.
OSGi is a specification that is really old, about 10 years, at least. It was originally designed for embedded devices. During the past two years, we have seen a lot of traction in the enterprise market to push OSGi. The main thing is that the next major version of ServiceMix, which will be ServiceMix 4.0, is based on OSGi and reuses the OSGi benefit.
The main driver behind that was mainly to get around some weaknesses of the JBI specification mainly related to the JBI packaging and class loader architecture. OSGi is really a nice specification for that and we decided to use it for the next version of ServiceMix.
Gardner: Now, we tend to see a little bit of politics oftentimes in the market around specifications, standards, who supports them, whether there is a competing approach, and where that goes. We’ve seen a bit of that in the Java Community Process over the years. I wonder, Adrian, if you might be able to set the table, if you will, around where these specifications are and what some of the commercial interests are?
For example, I know that IBM is quite strong behind OSGi, and Oracle has backed it to an extent as well. These guys, obviously, have quite a bit clout in the market. Set the table on the vendors and the specification situation now.
Sticking with JBI 1.0
Trenaman: JBI is currently at version 1.0, or 1.11 actually. There is a JBI 2.0 expert group, and I believe they are working under JSR 312. So, I think there’s work going on to advance that specification.
However, if you look at what the vendors are doing -- be it Sun, Progress, or Red Hat through JBoss -- I think the vendors are all sticking with JBI 1.0 at the moment, making customers successful with that version of the spec and in anticipation of a new version of the spec. But, I believe it’s quite quiet. Guillaume, is that correct, for 2.0?
Nodet: Yes. I am part of the 2.0 expert group for JBI and the activity has been quite low recently. One main driver behind JBI 2.0 is to refocus on what I explained is the key point of the JBI 1.0 specification, which is the concept of normalized exchanges and the normalized message router.
The goal of the JBI 2.0 Expert Group I think is to refocus on that and making JBI play much more nicely with other specifications that somewhat are seen as opponents to JBI, like SCA, and also play more nicely with OSGi because ServiceMix is not the only JBI implementation that goes towards the OSGi way. So we want also to be sure that everything aligns correctly.
Gardner: Just so listeners can understand, what is it about OSGi that is valuable or beneficial as a container in an architectural approach, when used in conjunction with the SOA architectural component?
Trenaman: OSGi is the top of the art, in terms of deployment. It really is what we’ve all wanted for years. I’ve lost enough follicles on my head fixing class-path issues and that kind of class-path hell.
OSGi gives us a badly needed packaging system and a component-based modular deployment system for Java. It piles in some really neat features in terms of life cycle -- being able to start and shut down services, define dependencies between services and between deployment bundles, and also then to do versioning as well.
The ability to have multiple versions of the same service in the same JVM with no class-path conflicts is a massive success. What OSGi really does is clean up the air in terms of Java deployment and Java modularity. So, for me, it's an absolute no-brainer, and I have seen customers who have led the charge on this. This modular framework is not necessarily something that the industry is pushing on the consumers. The consumers are actually pulling us along.
I have worked with customers who have been using OSGi for the last year-and-a-half or two years, and they are making great strides in terms of making their application architecture clean and modular and very easy and flexible to deploy. So, I’ve seen a lot of goodness come out of OSGi and the enterprise. You mentioned politics earlier on, Dana, and the politics for me are interesting on the number of levels.
Here is my take on it. The first level is on the OSGi core platform, and what you’ve got there is a number of players who are all, in some sense I guess, competing to get the de-facto standard implementation or reference implementation. I think Eclipse Equinox emerges as the winner. They are now strongly backed by IBM.
The key players
And in the Apache Software Foundation you’ve got Felix. One of the other key players will be Knopplerfish OSGi, which is really Makewave, and they deliver Knopplerfish under a BSD-style license. So, we have some healthy competition there, but I guess in terms of feature build out Equinox seems to be the winner in that area.
That's one way of looking at it. The other thing is, if you look at your traditional app server vendors and what they are doing, IBM, Oracle, Red Hat, and Sun have all put OSGi, or are about to put OSGi, within their application servers. This is a massive movement.
I think it's interesting that OSGi is no longer a differentiator. It’s actually an important gatekeeper. You have to have it. This is a wave that the industry and that our customers are all riding, and I think they are very welcoming to it.
Politically, all of the app server vendors seem to be massively behind OSGi and supportive of it. The other area that maybe you alluded to is that in the broader Java community, there’s been a debate that's gone for some time now about JSR 277, which is the Java Community Process attempt at Java modules. The scene there is that JSR 277 overlaps massively with what OSGi intends to achieve, or rather has already achieved.
That starts getting messy all over again, because Java 7.0 will include JSR 277. So the future of Java seems to have hooked into this Java module specification, and not taking what would be the sensible choice, which would be to follow an OSGi based model, or at least to passionately embrace OSGi and weave it in a very nice way into JSR 277.
So, there is still some distance to go there on that debate over which one actually gets accepted and gets embraced by the community. I think the happiest conclusion for that is where JSR 277 really does embrace what OSGi has done, and actually, in a sense, builds support into the Java language for OSGi.
Gardner: Clearly, the momentum around OSGi has been substantial. I’ve been amazed at how far this has come so quickly.
Trenaman: Exactly.
Gardner: Now, IONA now within Progress Software, is in this not just for “peace on earth and good will toward men.” With the latest FUSE version being 4.0, you have a certification, support, and enterprise-ready service value around the ServiceMix core. Is there something about OSGi that helps Progress in delivering this to market, given the modularity and the better control and management aspects? I am thinking, if I am in certification and enterprise-ready mode for these, that OSGi actually helps me, is that correct?
It's a community issue
Trenaman: My perspective on that would be that embracing of OSGi in FUSE is a community issue. It’s the community that's driven that and that's a part of ServiceMix. So, this is something that we in Progress now are quite happy to embrace and then take into FUSE.
For me, what the OSGi gives us is clearly a much better plug-in framework, into which we can drop value-added services and into which we can extend. I think the OSGi framework is great for that, as well as in terms of management, maybe moving toward grid computing. The stuff that we get from OSGi allowed us to be far more dynamic in the way we provision services.
Gardner: Great. Now, you mentioned the big “grid” word. A lot is being talked about these days in cloud computing, and there’s an interesting intersection here between open-source early adopters and the very technology savvy providers or companies and the cloud phenomenon.
We’ve seen some quite successful cloud implementations at such organizations as Google, Yahoo!, and Amazon, and we’re starting to see more with chat in the market from Microsoft and IBM that they are going to get into this as well.
These are the organizations that are looking for control, the ability to extend code and “roll their own.” That's where their value add is. What's the intersection between SOA, open-source infrastructure, and these cloud implementations? Then, we’ll talk about where these clouds might go in terms of enterprises themselves. Who wants to take the high view on the cloud and open-source SOA discussion?
Trenaman: A lot of SOA is down to simply "Good Design 101." The separation of the interface from the implementation is absolutely key, and then location independence, as well. You know, being able to access a service of some kind and actually not really care exactly where that is on the cloud, so that the whole infrastructure behind the service is transparent. You do not get to see it.
SOA brings some very nice concepts in terms of contract-first design and standard-based specification of interfaces, be they using WSDL or just plain old XML and REST -- or even XML and JMS.
I think the fact that we can now define in a well-understood way what these services are, and that allows us to get the data into and out of the cloud in a standardized way. I think that's massively important. That's one of the things that SOA brings to the cloud that becomes very important.
What open-source brings to cloud, apart from quality software against which to build massively distributed systems. What it brings is maybe a business model or a deployment model that actually suits the cloud.
I think of the traditional software licensing models for closed source where you are charging per CPU. When you look at massive cloud deployments with virtual machines on many different physical hardware boxes, those models just don't seem to work.
Gardner: A great deal of virtualization is taking place in these cloud infrastructures.
A natural approach
Trenaman: I think open source becomes a very natural and desirable approach in terms of the technologies that you are going to use in terms of accessing the cloud and actually implementing services on the cloud. Then, in order to get those services there in the first place, SOA is pivotal. The best practices and designs that we got from the years we have been doing SOA certainly come into play there.
Gardner: Let's move into this notion of a private cloud, which also requires us to understand a hybrid, or managing what takes place within a private, on-premises cloud infrastructure -- and then some of these other available services from other large consumer-facing and business-facing cloud providers.
Vendors and, in many cases, community development organizations are starting to salivate over this opportunity to provide the software, services, and support in helping enterprises create that more efficient, high availability, much more creative utilization range incumbent in a well-designed cloud infrastructure or grid or utility infrastructure.
Trenaman: Sure.
Gardner: It seems unlikely that an organization creating one of these clouds is going to go out and just buy it out of the box. It seems much more likely that, at least for the early adoption stages, this is going to be a great opportunity to be exerting your own special sauce as an internal IT organization, well versed in open-source community development projects and then delivering services back to your employees and your customers and your business partners in such a way that you can really reduce your total cost, gain agility, and gain more control.
Let's go to Guillaume. How do you see ServiceMix, in particular, playing in this movement, now that we are just starting to see the opening innings of private cloud infrastructure?
Nodet: ServiceMix has long been a way that you can distribute your SOA artifacts. ServiceMix is an ESB and by nature, it can be distributed, so it's really easy to start several instances of ServiceMix and make them seamlessly talk together in a high availability way.
The thing that you do not really see yet is all the management and all the monitoring stuff that is needed when you deploy in such an architecture. So ServiceMix can really be used readily to fulfill the core infrastructure.
ServiceMix itself does not aim at providing all the management tools that you could find from either commercial vendors or even open-source. So, on this particular topic, ServiceMix, backed by Progress, is bringing a lot of value to our customers. Progress now has the ability to provide such software.
Gardner: So, Progress has had quite a long history, several decades, in bringing enterprise development and deployment strategies, platforms, tools, a full solution. This seems to be a pretty good heritage combined with what community development can offer in starting to craft some of these solutions for private clouds and also to manage the boundaries, which I think is essential.
I can see an ESB really taking on a significantly larger role in managing the boundaries between and among different cloud implementations for integration, data portability, and transactional integration. Adrian anything to further add to that.
Dynamic provisioning
Trenaman: Certainly, you could always see the ESBs being sort of on the periphery of the cloud, getting data in and out. That's a clear use case. There is something a little sweeter, though, about ServiceMix, particularly ServiceMix 4, because it's absolutely geared for dynamic provisioning.
You can imagine having an instance of ServiceMix 4 that you know is maybe just an image that you are running on several virtual machines. The first thing it does is contact a grid controller and says, “Well, okay, what bundles do you want me to deploy?” That means we can actually have the grid controller farming out particular applications to the containers that are available.
If a container goes down, then the grid controller will restart applications or bundles on different computing resources. With OSGi at the core of ServiceMix, at the core of the ESB, that’s a step forward now in terms of dynamic provisioning and really like an autonomous competing infrastructure.
Nodet: Another thing I just want to add about ServiceMix 4, complementing what Adrian, just said is that ServiceMix split into several sub-projects. One of them is ServiceMix Kernel, which is an OSGi enhanced runtime that can be used for provisioning education, and this container is able to deploy virtually any kind of abstract. So, it can support Web applications, and it can support JBI abstracts, because the JBI container is reusing it, but you can really deploy anything that you want.
So, this piece of software can really be leveraged in cloud infrastructure by virtually deploying any application that you want. It could be plain Web services without using an ESB if you don’t have such a need. So it's really pervasive.
Gardner: We were quite early in this whole definition of what private cloud would or wouldn't be. Even the word “cloud,” of course, is quite nebulous nowadays.
I do see a huge opportunity here, given also the economic pressures that many organizations are going to be facing in the coming years. It's really essential to do more with less. As we move toward these cloud implementations, you certainly want to be able to recognize that it isn't defined. It's a work in progress, and having agility, flexibility, visibility into the code, understanding the origin for the code, and the licensing and so forth, I think is extremely important.
Trenaman: It’s massively important for anyone building the cloud, particularly a public cloud. That has got to be watched with total care.
Gardner: We’ve been talking about SOA infrastructure, getting some updates and refreshers on the ServiceMix and Apache Foundation approaches. talking to some community and thought leaders. We've learned a little bit more also about Progress Software and FUSE 4.0.
I’m very interested and excited about these cloud opportunities for developers to use as they already are. The uptake in Amazon Web Services for development activities and test-and-deploy scenarios and performance testing has been astonishing.
Microsoft is going to be right behind them with an appeal to developers to build on a Microsoft cloud. These are going to be ongoing and interesting, and so managing them is going to be critical to their success. A key differentiator from one enterprise to another it is how well they can take advantage of these, and manage the boundaries quite well.
I want to thank our participants. We have been joined by Guillaume Nodet. He is the software architect at Progress Software and vice president of Apache ServiceMix. Thank you, Guillaume, we really appreciate your input.
Nodet: No problem. I am glad that we have been able to do this.
Gardner: We have also been joined by Adrian Trenaman. He is distinguish consultant at Progress Software. Great to have you with us, Adrian.
Trenaman: It's a pleasure.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. I want to thank our sponsor for today's podcast, Progress Software. We’re coming to you through the BriefingsDirect Network. Thanks for listening and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.
Transcript of a BriefingsDirect podcast with Guillaume Nodet and Adrian Trenaman of Progress Software on directions and trends in SOA and open source. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about open source, service-oriented architecture (SOA) developments, and trends.
We are going to catch up and get a refresher on some important open-source software projects in the Apache Software Foundation. We’ll be looking at the Apache ServiceMix enterprise service bus (ESB), and the toolkit, and we are going to talk with some thought leaders and community development leaders to assess the market for these products, particularly in the context of cloud computing, which is certainly getting a lot of attention these days.
We'll also look at the context around such technologies as OSGi and Java Business Integration (JBI). We want to also think about what this means for enterprise-caliber SOA, particularly leveraging open-source projects. [Access more FUSE Community podcasts.]
To help us sort out and better understand the open-source SOA landscape, we’re joined by Guillaume Nodet, software architect at Progress Software and vice president of Apache ServiceMix at Apache. Welcome to the show, Guillaume.
Guillaume Nodet: Thank you.
Gardner: We are also joined by Adrian Trenaman, distinguished consultant at Progress Software. Hey, Adrian.
Adrian Trenaman: Hey, Dana. How is it going?
Gardner: Good. Now, we are starting to see different patterns of adoption and use-case scenarios around SOA, and open-source projects. Counterpart offerings for certification and support, such as the FUSE offerings from Progress, are getting more traction in interesting ways. The role of ESBs, I think as we can safely say, it is expanding.
The role for management and policy and rules and roles is becoming much more essential, not on a case-by-case basis or tactical basis, but more from a holistic management overview of services and other aspects of IT development and deployment.
First I want to go to Guillaume. Give us a quick update on Apache ServiceMix, and how you see it being used in the market now?
Nodet: Apache ServiceMix is one of the top-level projects at the Apache Software Foundation. It was started back in 2005, and was graduated as a top-level project a year-and-a-half ago. ServiceMix is an open-source ESB and it's really a well-known ESB for several reasons, which we’ll come to later. It's really a full-featured ESB that is widely used in a whole range of companies from government to banking applications. There’s very wide use of ServiceMix.
Gardner: Tell us a little bit about your background, and how you became involved. How long have you been working on ServiceMix, and what led you up to getting involved?
Nodet: Back in 2004, I was working at a small company based in France, and we were looking for an ESB for internal purposes. I began to do some research on the open-source ESBs available at that time. I was involved in the Mule Project and I became a committer in my spare time, and had been one of the main committers for six months.
In the summer of 2005, my company was firing people for economical reasons, and I decided to take a break and leave the company. So I sent an email to James Strachan, who was just starting ServiceMix, and that's how I became involved. I was hired by LogicBlaze at the time, which has been acquired by IONA and now Progress.
Gardner: Tell us a little bit more about the context of the ServiceMix ESB in some of the other Apache Software Foundation projects, just so our listeners understand that this isn't necessarily standalone. It can be used, of course, standalone, but it fits into a bigger picture, when it comes to SOA infrastructure. Maybe you could just explain that landscape as it stands now.
The bigger picture
Nodet: ServiceMix is an ESB and reuses lots of other Apache projects. The main ones which ServiceMix reuse is Apache ActiveMQ which is a message broker so it is for the JMS backbone infrastructure. We also heavily use Apache CXF, which is a SOAP stack that integrates nicely in ServiceMix. One of the other projects that we use is Apache Camel, which is a sub-project of Apache ActiveMQ, is a message router, which is really efficient and it uses DSL to be able to configure routers very easily. So these are the three main projects that we use.
Of course, for ServiceMix 4.0, we are also using the Apache Felix OSGi Framework, and lots of other projects that we use throughout ServiceMix. There are really big ties between ServiceMix and the other projects. Another project that we can leverage in ServiceMix is Apache ODE, which is the business process execution language (BPEL) Engine.
Gardner: Now, it's not always easy to determine the number of implementations, particularly in production, for open-source projects and code. It's a bit easier when you have a commercial vendor. You can track their sales or revenues and you have a sense of what the market is doing.
Do you have any insight into what's been going on, in a larger trend around these SOA open-source projects in terms of implementation volumes? Are we still in test, are people in pilot, or are we seeing a bit more. And, what trends are there around actual production implementation? I'll throw that to either one, Adrian or Guillaume.
Trenaman: I’m happy to chip in there. We’ve seen, quite a lot of work in terms of real-world sales. So you started in ServiceMix, obviously. We have been using ServiceMix for some time with our customers, and we have seen it used and deployed, in anger, if you will. What's interesting for me is the number of different kinds of users out there, the different markets that it gets deployed in. We have had users in airline solutions, in retail, and extensive use in government situations as well.
We recently finished a project in mobile health, where we used ServiceMix to take information from a government health backbone, using HL7 formatted messages, and get that information onto the PDAs of the health-care officials like doctors and nurses. So this is a really, really interesting use case in the healthcare arena, where we’ve got ServiceMix in deployment.
It’s used in a number of cases as well for financial messaging. Recently, I was working with a customer, who hoped to use ServiceMix to route messages between central securities depositories, so they were using SWIFT messages over ServiceMix. We’re getting to see a really nice uptake of new users in new areas, but we also have lots of battle-hardened deployments now in production.
Gardner: One of the nice things about this trend towards adoption is that you often get more contributions back into the project. Maybe it would be good now to understand who is involved with Apache, who is really contributing, and who is filling out the feature sets and defining the requirements around ServiceMix. Guillaume, do you have any thoughts about who is really behind this in terms of the authoring and requirements?
From the community
Nodet: The main thing is that everything comes from the community at large. It’s mainly users asking how they can implement a given use case. Sometimes, we don't have everything set up to fulfill the use case in the easiest way. In such a case, we try to enhance ServiceMix to cover more use cases.
In terms of contributors, we have lots of people working for different companies. Most of them are IT companies who are working and implementing SOA architecture for one of their customers and they are using ServiceMix.
We have a number of individual contractors who do some consulting around ServiceMix and they are contributing back to the software. So, it's really a diverse community. Progress is, obviously, one of the big proponents of Apache ServiceMix. As you have said, we run our business using the FUSE family of projects.
So, it's really a very diverse community and with different people from different origins, from everywhere in the world. We have Italian guys, we have, obviously, US people, and we have a big committee.
Gardner: The JBI specification has been quite central to ServiceMix. If you could, give us an update on what JBI, as its own spec, has been up to, and what that means for ServiceMix, and ultimately FUSE. Furthermore, let's get into some of the OSGi developments. It has really become hot pretty quickly in the market. So what's up with JBI and OSGi?
Nodet: The JBI specification has been out since the beginning of 2005. It defines an architecture to build some ESBs in Java. The main thing is that the key concept is normalized exchanges. This means that you can deploy components on the JBI container, and all of these components will be able to work together without any problems because they share a common knowledge of exchanges, and the messages between components are implemented. This is really a key point.
Anyone can grab a third party component from outside ServiceMix. There are a number of examples of components that exist, and you can grab such a component and deploy it in ServiceMix and it will just work.
That's really one of the main points behind the JBI specification. It’s a Java centric specification. I mean that the implementation has to be done in Java, but ServiceMix allows a lot of different clients from other technologies to jump into the bus and exchange data with other components.
So one of the things that we use for that is a STOMP protocol, which is a text-based messaging protocol. We have lots of different implementations from Ruby, Python, JavaScript and lots of different languages that you can use to talk to the ServiceMix bus.
OSGi is a specification that is really old, about 10 years, at least. It was originally designed for embedded devices. During the past two years, we have seen a lot of traction in the enterprise market to push OSGi. The main thing is that the next major version of ServiceMix, which will be ServiceMix 4.0, is based on OSGi and reuses the OSGi benefit.
The main driver behind that was mainly to get around some weaknesses of the JBI specification mainly related to the JBI packaging and class loader architecture. OSGi is really a nice specification for that and we decided to use it for the next version of ServiceMix.
Gardner: Now, we tend to see a little bit of politics oftentimes in the market around specifications, standards, who supports them, whether there is a competing approach, and where that goes. We’ve seen a bit of that in the Java Community Process over the years. I wonder, Adrian, if you might be able to set the table, if you will, around where these specifications are and what some of the commercial interests are?
For example, I know that IBM is quite strong behind OSGi, and Oracle has backed it to an extent as well. These guys, obviously, have quite a bit clout in the market. Set the table on the vendors and the specification situation now.
Sticking with JBI 1.0
Trenaman: JBI is currently at version 1.0, or 1.11 actually. There is a JBI 2.0 expert group, and I believe they are working under JSR 312. So, I think there’s work going on to advance that specification.
However, if you look at what the vendors are doing -- be it Sun, Progress, or Red Hat through JBoss -- I think the vendors are all sticking with JBI 1.0 at the moment, making customers successful with that version of the spec and in anticipation of a new version of the spec. But, I believe it’s quite quiet. Guillaume, is that correct, for 2.0?
Nodet: Yes. I am part of the 2.0 expert group for JBI and the activity has been quite low recently. One main driver behind JBI 2.0 is to refocus on what I explained is the key point of the JBI 1.0 specification, which is the concept of normalized exchanges and the normalized message router.
The goal of the JBI 2.0 Expert Group I think is to refocus on that and making JBI play much more nicely with other specifications that somewhat are seen as opponents to JBI, like SCA, and also play more nicely with OSGi because ServiceMix is not the only JBI implementation that goes towards the OSGi way. So we want also to be sure that everything aligns correctly.
Gardner: Just so listeners can understand, what is it about OSGi that is valuable or beneficial as a container in an architectural approach, when used in conjunction with the SOA architectural component?
Trenaman: OSGi is the top of the art, in terms of deployment. It really is what we’ve all wanted for years. I’ve lost enough follicles on my head fixing class-path issues and that kind of class-path hell.
OSGi gives us a badly needed packaging system and a component-based modular deployment system for Java. It piles in some really neat features in terms of life cycle -- being able to start and shut down services, define dependencies between services and between deployment bundles, and also then to do versioning as well.
The ability to have multiple versions of the same service in the same JVM with no class-path conflicts is a massive success. What OSGi really does is clean up the air in terms of Java deployment and Java modularity. So, for me, it's an absolute no-brainer, and I have seen customers who have led the charge on this. This modular framework is not necessarily something that the industry is pushing on the consumers. The consumers are actually pulling us along.
I have worked with customers who have been using OSGi for the last year-and-a-half or two years, and they are making great strides in terms of making their application architecture clean and modular and very easy and flexible to deploy. So, I’ve seen a lot of goodness come out of OSGi and the enterprise. You mentioned politics earlier on, Dana, and the politics for me are interesting on the number of levels.
Here is my take on it. The first level is on the OSGi core platform, and what you’ve got there is a number of players who are all, in some sense I guess, competing to get the de-facto standard implementation or reference implementation. I think Eclipse Equinox emerges as the winner. They are now strongly backed by IBM.
The key players
And in the Apache Software Foundation you’ve got Felix. One of the other key players will be Knopplerfish OSGi, which is really Makewave, and they deliver Knopplerfish under a BSD-style license. So, we have some healthy competition there, but I guess in terms of feature build out Equinox seems to be the winner in that area.
That's one way of looking at it. The other thing is, if you look at your traditional app server vendors and what they are doing, IBM, Oracle, Red Hat, and Sun have all put OSGi, or are about to put OSGi, within their application servers. This is a massive movement.
I think it's interesting that OSGi is no longer a differentiator. It’s actually an important gatekeeper. You have to have it. This is a wave that the industry and that our customers are all riding, and I think they are very welcoming to it.
Politically, all of the app server vendors seem to be massively behind OSGi and supportive of it. The other area that maybe you alluded to is that in the broader Java community, there’s been a debate that's gone for some time now about JSR 277, which is the Java Community Process attempt at Java modules. The scene there is that JSR 277 overlaps massively with what OSGi intends to achieve, or rather has already achieved.
That starts getting messy all over again, because Java 7.0 will include JSR 277. So the future of Java seems to have hooked into this Java module specification, and not taking what would be the sensible choice, which would be to follow an OSGi based model, or at least to passionately embrace OSGi and weave it in a very nice way into JSR 277.
So, there is still some distance to go there on that debate over which one actually gets accepted and gets embraced by the community. I think the happiest conclusion for that is where JSR 277 really does embrace what OSGi has done, and actually, in a sense, builds support into the Java language for OSGi.
Gardner: Clearly, the momentum around OSGi has been substantial. I’ve been amazed at how far this has come so quickly.
Trenaman: Exactly.
Gardner: Now, IONA now within Progress Software, is in this not just for “peace on earth and good will toward men.” With the latest FUSE version being 4.0, you have a certification, support, and enterprise-ready service value around the ServiceMix core. Is there something about OSGi that helps Progress in delivering this to market, given the modularity and the better control and management aspects? I am thinking, if I am in certification and enterprise-ready mode for these, that OSGi actually helps me, is that correct?
It's a community issue
Trenaman: My perspective on that would be that embracing of OSGi in FUSE is a community issue. It’s the community that's driven that and that's a part of ServiceMix. So, this is something that we in Progress now are quite happy to embrace and then take into FUSE.
For me, what the OSGi gives us is clearly a much better plug-in framework, into which we can drop value-added services and into which we can extend. I think the OSGi framework is great for that, as well as in terms of management, maybe moving toward grid computing. The stuff that we get from OSGi allowed us to be far more dynamic in the way we provision services.
Gardner: Great. Now, you mentioned the big “grid” word. A lot is being talked about these days in cloud computing, and there’s an interesting intersection here between open-source early adopters and the very technology savvy providers or companies and the cloud phenomenon.
We’ve seen some quite successful cloud implementations at such organizations as Google, Yahoo!, and Amazon, and we’re starting to see more with chat in the market from Microsoft and IBM that they are going to get into this as well.
These are the organizations that are looking for control, the ability to extend code and “roll their own.” That's where their value add is. What's the intersection between SOA, open-source infrastructure, and these cloud implementations? Then, we’ll talk about where these clouds might go in terms of enterprises themselves. Who wants to take the high view on the cloud and open-source SOA discussion?
Trenaman: A lot of SOA is down to simply "Good Design 101." The separation of the interface from the implementation is absolutely key, and then location independence, as well. You know, being able to access a service of some kind and actually not really care exactly where that is on the cloud, so that the whole infrastructure behind the service is transparent. You do not get to see it.
SOA brings some very nice concepts in terms of contract-first design and standard-based specification of interfaces, be they using WSDL or just plain old XML and REST -- or even XML and JMS.
I think the fact that we can now define in a well-understood way what these services are, and that allows us to get the data into and out of the cloud in a standardized way. I think that's massively important. That's one of the things that SOA brings to the cloud that becomes very important.
What open-source brings to cloud, apart from quality software against which to build massively distributed systems. What it brings is maybe a business model or a deployment model that actually suits the cloud.
I think of the traditional software licensing models for closed source where you are charging per CPU. When you look at massive cloud deployments with virtual machines on many different physical hardware boxes, those models just don't seem to work.
Gardner: A great deal of virtualization is taking place in these cloud infrastructures.
A natural approach
Trenaman: I think open source becomes a very natural and desirable approach in terms of the technologies that you are going to use in terms of accessing the cloud and actually implementing services on the cloud. Then, in order to get those services there in the first place, SOA is pivotal. The best practices and designs that we got from the years we have been doing SOA certainly come into play there.
Gardner: Let's move into this notion of a private cloud, which also requires us to understand a hybrid, or managing what takes place within a private, on-premises cloud infrastructure -- and then some of these other available services from other large consumer-facing and business-facing cloud providers.
Vendors and, in many cases, community development organizations are starting to salivate over this opportunity to provide the software, services, and support in helping enterprises create that more efficient, high availability, much more creative utilization range incumbent in a well-designed cloud infrastructure or grid or utility infrastructure.
Trenaman: Sure.
Gardner: It seems unlikely that an organization creating one of these clouds is going to go out and just buy it out of the box. It seems much more likely that, at least for the early adoption stages, this is going to be a great opportunity to be exerting your own special sauce as an internal IT organization, well versed in open-source community development projects and then delivering services back to your employees and your customers and your business partners in such a way that you can really reduce your total cost, gain agility, and gain more control.
Let's go to Guillaume. How do you see ServiceMix, in particular, playing in this movement, now that we are just starting to see the opening innings of private cloud infrastructure?
Nodet: ServiceMix has long been a way that you can distribute your SOA artifacts. ServiceMix is an ESB and by nature, it can be distributed, so it's really easy to start several instances of ServiceMix and make them seamlessly talk together in a high availability way.
The thing that you do not really see yet is all the management and all the monitoring stuff that is needed when you deploy in such an architecture. So ServiceMix can really be used readily to fulfill the core infrastructure.
ServiceMix itself does not aim at providing all the management tools that you could find from either commercial vendors or even open-source. So, on this particular topic, ServiceMix, backed by Progress, is bringing a lot of value to our customers. Progress now has the ability to provide such software.
Gardner: So, Progress has had quite a long history, several decades, in bringing enterprise development and deployment strategies, platforms, tools, a full solution. This seems to be a pretty good heritage combined with what community development can offer in starting to craft some of these solutions for private clouds and also to manage the boundaries, which I think is essential.
I can see an ESB really taking on a significantly larger role in managing the boundaries between and among different cloud implementations for integration, data portability, and transactional integration. Adrian anything to further add to that.
Dynamic provisioning
Trenaman: Certainly, you could always see the ESBs being sort of on the periphery of the cloud, getting data in and out. That's a clear use case. There is something a little sweeter, though, about ServiceMix, particularly ServiceMix 4, because it's absolutely geared for dynamic provisioning.
You can imagine having an instance of ServiceMix 4 that you know is maybe just an image that you are running on several virtual machines. The first thing it does is contact a grid controller and says, “Well, okay, what bundles do you want me to deploy?” That means we can actually have the grid controller farming out particular applications to the containers that are available.
If a container goes down, then the grid controller will restart applications or bundles on different computing resources. With OSGi at the core of ServiceMix, at the core of the ESB, that’s a step forward now in terms of dynamic provisioning and really like an autonomous competing infrastructure.
Nodet: Another thing I just want to add about ServiceMix 4, complementing what Adrian, just said is that ServiceMix split into several sub-projects. One of them is ServiceMix Kernel, which is an OSGi enhanced runtime that can be used for provisioning education, and this container is able to deploy virtually any kind of abstract. So, it can support Web applications, and it can support JBI abstracts, because the JBI container is reusing it, but you can really deploy anything that you want.
So, this piece of software can really be leveraged in cloud infrastructure by virtually deploying any application that you want. It could be plain Web services without using an ESB if you don’t have such a need. So it's really pervasive.
Gardner: We were quite early in this whole definition of what private cloud would or wouldn't be. Even the word “cloud,” of course, is quite nebulous nowadays.
I do see a huge opportunity here, given also the economic pressures that many organizations are going to be facing in the coming years. It's really essential to do more with less. As we move toward these cloud implementations, you certainly want to be able to recognize that it isn't defined. It's a work in progress, and having agility, flexibility, visibility into the code, understanding the origin for the code, and the licensing and so forth, I think is extremely important.
Trenaman: It’s massively important for anyone building the cloud, particularly a public cloud. That has got to be watched with total care.
Gardner: We’ve been talking about SOA infrastructure, getting some updates and refreshers on the ServiceMix and Apache Foundation approaches. talking to some community and thought leaders. We've learned a little bit more also about Progress Software and FUSE 4.0.
I’m very interested and excited about these cloud opportunities for developers to use as they already are. The uptake in Amazon Web Services for development activities and test-and-deploy scenarios and performance testing has been astonishing.
Microsoft is going to be right behind them with an appeal to developers to build on a Microsoft cloud. These are going to be ongoing and interesting, and so managing them is going to be critical to their success. A key differentiator from one enterprise to another it is how well they can take advantage of these, and manage the boundaries quite well.
I want to thank our participants. We have been joined by Guillaume Nodet. He is the software architect at Progress Software and vice president of Apache ServiceMix. Thank you, Guillaume, we really appreciate your input.
Nodet: No problem. I am glad that we have been able to do this.
Gardner: We have also been joined by Adrian Trenaman. He is distinguish consultant at Progress Software. Great to have you with us, Adrian.
Trenaman: It's a pleasure.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. I want to thank our sponsor for today's podcast, Progress Software. We’re coming to you through the BriefingsDirect Network. Thanks for listening and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.
Transcript of a BriefingsDirect podcast with Guillaume Nodet and Adrian Trenaman of Progress Software on directions and trends in SOA and open source. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
Thursday, February 12, 2009
TOGAF 9 Advances IT Maturity While Offering More Paths to Architecture-Level IT Improvement
Transcript of a podcast on the evolution of the TOGAF 9 architectural framework, announced at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, February 2009.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect.
Today, we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group’s 21st Enterprise Architecture Practitioners Conference in San Diego, Feb. 3, 2009. Our topic for this podcast, which is part of a series of podcasts on events and major topics of this conference, centers on TOGAF 9, the newly released enterprise architecture framework.
The framework, the latest in the series, was released here Feb. 2 at the conference, and it really represents a departure for The Open Group and for enterprise architecture frameworks in general. It's larger, more mature, and modular to allow folks to enter it from a variety of perspectives. It takes on a much more significant business services and accomplishments perspective.
While IT practitioners and architects will be looking over TOGAF 9 deeply, it’s also going to be of interest to the business side of the enterprise and will be a way for them to understand more about how IT can service their business needs.
To guide us through our discussion on the evolution of TOGAF 9, where it's come from and where it is today, we're joined by Robert Weisman, CEO and principal consultant for Build The Vision, based in Ottawa. Welcome to show, Robert.
Robert Weisman: Delighted to be here.
Gardner: We're also joined by Mike Turner, an enterprise architect at Capgemini, based in London. Welcome to the show.
Mike Turner: Thanks, Dana.
Gardner: It's been my contention for some time now that architecture is destiny. How well you do architecture has a deep impact on your cost, your benefits, your quality of services, and ultimately, how competitive and well run you are as an enterprise.
Let’s go first to Robert. Do you agree that architecture is destiny, and is it perhaps more so now than ever?
Weisman: I can see architecture being an integral part of the business planning process. It structures the business plans and makes sure that the objectives are realizable. In other words, we can use the acronym SMART, specific, measurable, actionable, realizable, and time bound. What TOGAF 9 does is provide an overarching vision and capability with which to cooperate.
Gardner: Let’s take the same question over to you, Mike, this notion that how well you do architecture is a rather important aspect of your competencies of business. [Read more on a panel discussion about the importance of enterprise architecture.]
Turner: Architecture is definitely a factor. I see architecture as a set of tools and techniques that can help you achieve what you want to do as a business. Taking architecture in isolation is not necessarily going to achieve the right things for your organization, because you actually need to have the direction as an input for architecture to support achievement of a particular outcome.
Architecture is really a vital tool for is being able to assure that the correct business outcome is achieved. You need to have a structured approach to how you define the problem space that businesses are facing, then define the solution space, and define how you move from where you are right now to where you want to be.
If that’s not managed in a structured and traceable way that takes you from strategy through to realization, it’s very easy to go off track. It’s very easy for people to reinterpret what the business needs. It's very easy for technology projects, in particular, to take on a life of their own and deliver something, but not necessarily the thing that was originally intended.
So, in some way, architecture is that essential toolkit to make sure that the achievement of change is realized effectively from a content perspective.
Gardner: Change, of course, is a very important aspect of business nowadays, with a difficult economic climate and rapid change across many different industries, how they finance themselves, what their customers are doing, as well as the supply chain. Before we get more deeply into TOGAF 9 and frameworks, what does architecture bring to the ability of an organization to change rapidly?
Mergers and acquisitions
Weisman: When you're talking about change in this climate, there's going to be a great many mergers and acquisitions. Having been through them, there are two ways of going through them -- painful and less painful. Architecture is certainly a less painful way of doing it.
If you want to use knowledge in a knowledge-based economy, you want to make sure, when you actually acquire a company, that they stay acquired, that they don’t just walk. You have to know what they have. You have to also know the value of the soft assets within a company, and that’s what architecture brings to the fore. It brings out clearly the full value of the company, and make sure, before you do an acquisition or a merger, that you can compare the companies and do due diligence to determine whether there is actually a fit.
Gardner: Mike Turner, how about this change aspect and how architecture might be a serious foundation for good change management?
Turner: That question would have a different answer depending on the type of change that you are looking and dealing with. There are some changes that organizations are prepared to encounter and are anticipating. In those cases, architecture is a really good tool to help you to become more effective at dealing with those changes as they happen.
A good example of that would be a large organization that’s on an acquisition trail of buying up small organizations that operate in a similar business model as they do. Using architecture as a technique, you can actually say, "When we acquire a business, we expect it to have these capabilities. This is how we would take those capabilities into our environment." You can quite quickly absorb that change by having a repeatable approach to deal with it.
In those kind of spaces, architecture is really key, because you're anticipating the change, can plan for it, and can manage it strategically. If you don’t do that, then you end up having to face the problem afresh every time you encounter this situation and become ineffective at dealing with those kinds of repeatable processes.
Gardner: What about the discipline that’s required through adoption of a framework, that then puts you in a position to be able to be fleet and agile, when the unanticipated changes are required?
Turner: The other class of change is the change that you weren’t expecting. In those situations, your organization needs to be structured or siloed in ways that actually allow you to quickly reorganize and do things that are unexpected.
In those kind of situations, there's a component where architecture is helpful and then there's a piece where a architecture probably isn’t going to help you at all, because you're dealing with something that’s outside of what you understand today.
Architecture can help you structure your organization so that it's flexible. Outside of that, you're really into the space of a more agile-type approach, where you're not prepared to deal with things, and you just need to try something out, do something quickly, do something tactical, and build from that.
Plan for change
Weisman: There's an old adage that a plan is a common basis for change. If you don’t have the plan or your architectural framework, change is very difficult. Secondly, there is the old Roman adage, which basically says that luck is only where opportunity meets preparation. Architecture is that preparation or part of the preparation for that.
Gardner: Let’s take a brief trip down memory lane. I spoke to Allen Brown, the CEO of The Open Group, and he said that 9 coming out was, in a sense, like giving birth. It was a long gestation period and then a rather difficult last few days. So now that its out, tell us what the frameworks were like leading up to TOGAF 9, and then particularly what differentiates or distinguishes 9. We'll start with you Robert.
Weisman: TOGAF 9, first of all, is more business focused. Before that it was definitely in the IT realm, and IT was essentially defined as hardware and software. The definition of IT in TOGAF 9 is the lifecycle management of information and related technology within an organization. It puts much more emphasis on the actual information, its access, presentation, and quality, so that it can provide not only transaction processing support, but analytical processing support for critical business decisions.
The gestation took five years. I've been part of the forum for five years working on the TOGAF 9. Part of the challenge was that we had such an incredible take up of TOGAF 8. Once a standard has been taken up, you can’t change it on a dime. You don’t want to change it on a dime, but you want to keep it dynamic, update it, and incorporate best practices. That would explain some of the gestation period. TOGAF 8 was very successful, and to get TOGAF 9 right, it was a little longer cycle, but I think it’s been well worth the wait.
Gardner: Mike, what more generally has been the shift or change over time in how frameworks have been developed? Obviously, they've gotten larger and are more inclusive, but more generally, as a character of what they're trying to accomplish, how have frameworks changed over the past 20 years?
Turner: If you look at the industry in general, we're going through a process where the IT industry is maturing and becoming more stable, and change is becoming more incremental in the industry. What you see in architecture frameworks is a cycle of discovery, invention, and then consolidation that follows, as consensus is reached.
One thing that’s really key about TOGAF 9 is that it takes a lot of ideas and practices that exist within individual organizations or proprietary frameworks, building a consensus around it, and releasing it into a public-domain context.
Once that happens, the value you can get from that approach increases exponentially. Now, you're not talking about going to one vendor and having to deal with one particular set of concepts, and then going to a different vendor and having to deal with another set of concepts, and dealing with the interoperability between those.
You're in a situation where the industry agrees this is the way to do things. Suddenly, the economies of scale that you can get from that, as all the participants in the industry starts to converge on that consensus, mean that you get a whole set of new opportunities about how you can use architecture.
Vendor and technology neutral
Gardner: For those listeners who might not be familiar, The Open Group is a vendor-neutral and technology-neutral consortium. TOGAF, which is The Open Group Architecture Framework, is free in its online form, and there's a charge for the printed version.
About 7,500 individuals currently hold TOGAF certification, which is another important aspect of TOGAF, basically approving that you have the knowledge, experience, and understanding to carry it through. To date, 90,000 copies of TOGAF framework have been downloaded and 20,000 hard copies have been sold.
Let’s go back to Robert Weisman. Let’s look a little deeper at what distinguishes TOGAF 9. We mentioned the modularity. There is also the deeper use of the architecture development method. There is also a bit more inclusive comfort, if you will, with cloud computing and service-oriented architecture (SOA), and thinking more of security, start to finish and holistically. Maybe we could go through a laundry list of what distinguishes TOGAF 9.
Weisman: There are many particular factors. TOGAF 9 is, in certain ways, an evolutionary change and in certain other ways a revolutionary change. The architecture development methodology has basically remained similar. However, transforming the architecture from concept into a reality has basically been expanded pretty dramatically, with a great many lessons learned. So, architecture transformation is a large one. Various architectural frameworks have been incorporated into it.
A great many concepts that allow enterprise architecture to be molded with operations management, with system design, portfolio management, business planning, and the Governance Institute's COBIT guidelines and other industry standards have also been incorporated into TOGAF.
Also, there's been a major contribution by such companies as Capgemini, with respect to artifacts and structure. The content meta model is a huge contribution and as a core contribution, but Mike can elaborate upon that.
Overall, it’s much more extensive and it covers much more of the issues that most CIOs and IT architects have to confront on a daily basis. The nice thing about TOGAF is that you don’t have to use it all. You can use bits of it. You can use a large chunk of it, or you can basically choose to use in its entirety. It’s a very modular and flexible framework that way.
Gardner: As I understand it, with 9 they have made a pathway. If you've already adopted 8, you have a bit of a head start, but you don’t have to have gone to 8 in order to start adopting 9. You can work through different modules and start fresh, which I think is a bit of a departure from the past.
Let’s go over to Mike at Capgemini. Tell us about the meta model, and particularly how the use of repositories for policy driven governance and for the organization of assets across both IT and business become relevant now. [More on how Capgemini views cloud computing.]
Addressing challenges
Turner: If we rewind to TOGAF 8 and talk about some of our experiences using TOGAF 8, that's probably a good way to frame what we've tried to add into TOGAF 9 to address some of those challenges that we have encountered.
TOGAF 8, in our experience, was a very powerful process that you could follow to develop architectures. Where you started to hit limitations with TOGAF 8 was around the work products that you produced as a part of executing the architecture development method.
So TOGAF 8 has a lot of language that talks quite informally about the type of activities that an architect would carry out and the type of work products that they would create.
For example, it discusses creating business scenarios and process models and looking at logical data models and physical data models. There's a lot of language in TOGAF 8 that refers to modeling concepts, but then there is nothing actually in TOGAF 8 that says, "This is what a good deliverable looks like," or "This is actually how you would approach modeling those concepts formally."
What we find are organizations that are using TOGAF 8 effectively have two choices. They can adopt the process and leave the content side of things quite open-ended, or they can adopt the process and select something else to do with the content.
At Capgemini, we had a proprietary internal framework for content prior to TOGAF 9. We did a lot of work taking TOGAF 8 process and Capgemini content framework and putting the two together. We found that to be a really effective combination.
What we also found was that, because of the proprietary nature of the Capgemini framework, it became quite difficult for organizations to adopt that configuration. While we're working entirely within a Capgemini environment and we've got control over the people, the skills, the knowledge, and the approach, that works really well. But, when you're looking at multi-vendor sourcing models or looking at upskilling an end user organization, it becomes a lot more difficult.
What we wanted to do with TOGAF 9 was to address that problem head on and to try to create something equivalent to the Capgemini proprietary framework in a way that allows incremental evolution out of TOGAF 8. We took a lot of the informal concepts that were defined in TOGAF 8 and tried to formalize those around some of our internal thinking for content.
Gardner: What is the upside now, since we've made this transition to 9, for the strategic use of repositories?
Turner: One of the things that we've been working on quite heavily over the past few years is getting the various tool vendors to support the Capgemini framework. We've got quite a long list of tool vendors supporting this framework model. What we are expecting is a small incremental effort for those same vendors to transition and make what are essentially cosmetic changes to be able to support the TOGAF 9 content framework.
Very soon, we'll be in a position where we're looking at a market for enterprise architecture tools, where there is now a level of consensus about how to structure models and how to represent them in a way that didn’t exist before. That can only be a good thing for enterprise repositories, because we're moving closer and closer to that consensus point about how content should be structured.
The problem that we're unable to solve is then to take that model, go one step further, and look at the actual operating model within a particular enterprise, how that enterprise chooses to assign roles and responsibilities for carrying out architecture, and how it chooses to federate governance and those kind of concerns. This is fundamental to how you structure repository, because the repository needs to reflect the partitioning that you actually hold within your organizational structure.
We'll see a big improvement, but it’s not the solution in its entirety.
Gardner: Repositories will include a number of different types of artifacts and services, and each organization will have a unique way of approaching that, given their legacy and their history. We do seem to have reached somewhat of a tipping point in recognizing that to manage complexity, to adopt SOA principles effectively and extend them holistically to start dabbling in cloud computing and take advantage of resources and assets available through that particular model or set of models. Does this increasingly require this organizational framework of repository. Do you agree with that Robert?
Underlying rigor
Weisman: No. I've been an enterprise architect now since 1985, and many of these terms come and go. Underlying it is a certain degree of rigor that the frameworks provide.
It doesn’t matter what environment you go into, but if you have a client with 500 definitions of client, their customers, and you're trying to integrate that to take an overview of the customer throughout goodness knows how many databases, what happens is there is certainly a cogent case for consolidating that.
Many organizations carry orders of magnitude more information than they need. The implications for the information technology infrastructure are immense, and the quality of information because of that is pitiful, not allowing the business executives to make proper decisions.
Whether you do cloud computing or not is immaterial. Whatever paradigm you choose, as long as you apply it in a professional and effective manner, it will work. Trying to use a silver-bullet type of approach and a new name to circumscribe rigorous engineering and professional principles would be a grave error.
Gardner: Okay, fair enough. What is it about TOGAF 9, in particular, that does grease the skids a bit for organizations to better adopt and utilize SOA principles, services like software-as-a-service (SaaS), or infrastructure-as-a-service, what we loosely call cloud nowadays?
Weisman: TOGAF was based on a foundational architecture called the Technical Reference Model, which came out of the U.S. many years ago. It's all service oriented.
The term SOA is old wine in new bottles. It's been around for a long time. If you just have a service catalog, if you have duplicate services, it becomes very evident. That’s one of the advantages of the repositories -- you can have an insight into what you actually have.
TOGAF, from its outset in the early 1990s, has been service oriented for that. Just by applying TOGAF, you have a chance of doing your Gap Analysis, of having the visibility into what you have, which makes it not only efficient, but effective from a business perspective.
Gardner: Anything to offer, Mike?
Two points of view
Turner: When you look at SOA, there are probably two different ways that you can think about IT. One offers quite limited benefits to an organization, and the other offers much greater benefit. At a technical level, there are a bunch of standards and design approaches referred to as SOA, that really deal with standardizing the way the applications talk to one another at a software level.
Implementing SOA in this technical sense isn't necessarily a bad thing, and there are certainly benefits to be had in terms of interoperability at a software level from implementing SOA principles. But, just working at that level on its own is not going to give you any business advantages. It’s just going to make it easier to execute development projects.
The power of thinking about services is much more centered on how you look at your organizational capability and how you can more effectively break down your organization into discrete capabilities that are not replicating the same data, business processes, and IT systems in multiple silos.
If you can have a more granular business organization, where you are replicating capability less, it’s much easier to change more quickly, it’s much easier to use those capabilities to do different things, and you see a step change in the performance of your business.
We need to get those kinds of SOA benefits. The first and most important question to ask is, "What are the services that I need in my business? How should I structure my business to make it meet the goals of the industry?" That may be flexibility, but there are actually some organizations or some parts of your enterprise where you actually don’t desire flexibility. You want stability, cost efficiency, and effectiveness in a much more linear, repeatable sense.
TOGAF allows you to understand what makes your business good and then identify what your services are in a way that considers all the different angles. Once that’s defined, you can then put the right technology underneath that to realize what the business is actually looking for. That’s something that can have an absolutely transformational effect on your business.
Gardner: You mentioned that architecture and SOA by themselves don't necessarily aid a business in achieving its goals, but TOGAF 9 has taken steps over this past five years to increase its relevance to business. Robert, explain how that takes place and what that really means?
Weisman: We're talking about services here. The old TOGAF used to talk in terms of the Technical Reference Model. That's still in 9, but we're looking at business services, as Mike was alluding to. We're looking at rationalizing business services and making sure that they're basically well supported by that.
It also assumes that, when you're doing your preliminary planning, you come up with a framework that recognizes the business operation model within your organization and that you have identified your stakeholders and what they actually want to see in the enterprise architecture framework.
Lack of vision
Most projects fail, because they don’t have proper preliminary planning, and they don’t basically go through the problem. They don’t go through the effort of putting a vision in place. As a consequence, they just jump into the architecture -- usually into the applications and technology architecture -- and they find themselves in trouble very quickly for that. They get a great deal of dissatisfaction.
Outsourcing is an excellent example where a high degree of enterprise architecture maturity correlates to a high degree of satisfaction from both the client and vendor of outsourcing services.
Satisfaction, according to Peter Weill’s book, Enterprise Architecture as Strategy, essentially goes from 50-50 with poorer enterprise architecture maturity to 90-90 with enterprise architecture maturity, and that’s satisfaction both for a client and vendor.
So it ends up being a win-win.
When I talk about outsourced services, they are not necessarily all technology either. They can be business processes that are now being outsourced as well, and it will work its way up the stack.
Gardner: We've talked about architecture as important, of course, but the people who then implement the architecture are quite important. To what degree is certification now a particularly relevant aspect of success in a down economy?
Labor issues and getting good people have been a challenge. There have been significant layoffs, but there has also been an increase in the demand for strong IT to support change in a dynamic business environment. Let’s start with you Robert, the role of certification in the year 2009?
Weisman: First of all, there are two dimensions of certification. For example in The Open Group, you have certification with respect to knowledge of the TOGAF methodology, and then you have IT architecture certification. IT architecture is much broader. It includes business architects and enterprise architects as well, and that takes a look at competencies.
There are no international standards for IT architecture. There are many consultancies that work globally. So, all of a sudden, you're called upon, but this provide a global standard and a global level of confidence with respect to the individuals.
The IT Architect Certification (ITAC) and the IT Services Certification (ITSC) that The Open Group are doing, will provide a level of comfort and assurance to clients that basically they are getting people with a uniform degree of competence.
With respect to the downturn, this is going to become important. Right now, most architects call themselves architects, but there is no international standard against which to measure them. That’s led to a great many architecture failures, which, when you examine them, are not surprising.
Using a standard methodology will also enable RFPs to be written rapidly. What happens is now when you say, "I want a vision as per TOGAF," everybody knows what the baseline is. Then, both suppliers and clients can come up with the assurance, saying, "These guys know what they're talking about," and they can put in a reasonable bid for that.
You're talking about the standardization of product and competencies. This is becoming increasingly important. Globally, there's a huge decrease in enrollment in computer science and computer engineering programs, because of the fact that clients aren’t recognizing these professional designations. Many people say there's no business case in going through an expensive degree program, when you can take a short course and have a very deep but very narrow competency in a particular field?
Certification, both from a competency point of view and from a product point of view, is the wave of the future and extremely important.
Gardner: Mike, how does Capgemini look at the certification process and how important it is for your clients?
Demonstrating capability
Turner: It’s very important, and there are two reasons why. If you look externally in trying to source resources from the market -- whether that’s through a subcontractor or to recruit individuals -- having certification is a good way for candidates to be able to demonstrate that they have reached a level of capability and also for potential employers to put in place a benchmark that filters out the noise.
They can spend much more time looking at individual candidates and assessing them as potential fits to the roles that they're trying to source. I wouldn’t say that certification necessarily guarantees that you get the right person, but it gets you to a short list much quicker.
Gardner: How about practitioners themselves? Is there a significant boost in the pay or ability to find the right jobs as a result of this TOGAF certification?
Turner: If you look at the UK market, there is a correlation between certification and higher pay, but I wouldn’t that that’s the absolute overriding factor.
Another angle to this is, if you look within an organization -- and Capgemini as an organization has a large number of architects, but our client base has architects that work in their organizations -- certification starts to outline a career path for architects within an organization and to allow them to develop themselves and demonstrate that they are improving in capability.
Capgemini has a very active certification program, which we run internally and which is based on experience, engagement, and community. We find that to be a very effective way to build and maintain a community and show professional development and mentoring within our internal environment. That’s something that we help our clients do as well.
Ultimately, architecture is about a network of people. It's about communicating effectively within that network, and then that network having a good face to all the stakeholders for architecture. Having training certification, professional development, and those factors can only be a good thing for building that practice.
Gardner: We're going to be wrapping up in a bit. It’s clearly too soon to look into the future. We just got TOGAF 9 out of the gate. I wonder if there isn’t any extrapolation or looking from the vision point of view where we have come from TOGAF 8 to TOGAF 9, to perhaps give some indication to our listeners as to where TOGAF and enterprise architecture frameworks in general are headed.
Let’s start with you, Robert, for our last question. What can we say, given what we now know about TOGAF 9, as to where the next TOGAF might lead us?
Weisman: There are many working groups right now working on TOGAF, the next generation, whatever it’s going to be called, for example, the Information Architecture Working Group and the like. They've been established and they're looking towards the future and the strategy for that.
Working together
What I see eventually is a lot of these architectural frameworks will start emerging. One of the beauties of TOGAF is that it works very well in conjunction with other architectural frameworks. Let’s say that you're using another architectural framework, which a lot of the industry verticals have. Normally they're model based and TOGAF is mainly process based. They come together, extremely well together, and this is a major strength.
You can’t say, "I'm using this. I can’t use TOGAF." TOGAF will help you deliver the other framework. One of the major issues with many of the other frameworks is that they're wonderfully detailed models, but there is no methodology in place with which to deliver them in a systematic manner. So, I see TOGAF not in terms of an über framework, but certainly a cooperative framework.
It’s also linked with other management frameworks and it’s going to be closer to project management, portfolio management, and the like, which should make it an easier transition. An integrative framework of choice might be a way of describing where TOGAF is going. It's going to be a pointer to other standards and how to integrate them within a company.
We're not there to duplicate the work of other wonderful organizations. It’s how to integrate all the wonderful work, because right now, for executives at the CIO and CEO level, it’s pretty confusing out there.
Gardner: Mike Turner, do you agree on that particular extrapolation in the future of more inclusivity and convergence across business types of frameworks, or are there other future elements of TOGAF we should consider?
Turner: Those are all valid points, and I'd add a few more. One thing we're going to see with TOGAF 9 being available now in the industry is that there would be a reaction to that. A lot of the frameworks and standards that sit around the edge of TOGAF are going to realign slightly to make themselves more consistent with how TOGAF works, which, as Bob mentioned, will help TOGAF integrate some of these different approaches. That will happen without changing TOGAF itself. It would just be that the industry will change to be more aligned around the TOGAF model.
In terms of TOGAF development, there's going to be a big focus on people and organizational aspects within TOGAF, trying to formalize the different skills that are required and the different places where you can use TOGAF within an organization.
Ultimately, that will lead to much greater specialization of the method that we have right now, because we have a single method that applies at a very strategic level and also at a very tactical level. As we understand the organizational context, we can start to be more specific about how the method is applied in different contexts.
Another trend is around the formalization of the specification content. We would expect to see, particularly around a standard for managing this kind of massive information that you are managing semantic content and mature, that TOGAF will start to embrace some of those standards. Looking at formal languages for specifying the methodology and putting the tool set itself within software tools that can be customized and configured is something that we would look to do.
Gardner: Well, that gives us quite a bit to look forward to, some more maturity, even though we have reached a significant milestone in the current level of maturity.
We have been talking about TOGAF 9, its introduction and where its come from and part of its evolution. Our conversation today comes to you through the support of The Open Group, and we are coming to you from the 21st Enterprise Architecture Practitioners Conference in San Diego, in February 2009.
I want to thank our panelists. We have been joined by Robert Weisman, CEO and principal consultant for Build The Vision. Thank you Robert.
Weisman: You're very welcome.
Gardner: Also Mike Turner, enterprise architect at Capgemini. Thanks so much, Mike.
Turner: Thanks.
Gardner: I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to BriefingsDirect. Thanks and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Transcript of a podcast on the development of the TOGAF 9 architectural framework, announced at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, February 2009. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:
The Open Group's CEO Allen Brown interview
Live panel discussion on enterprise architecture trends
Reporting on the TOGAF 9 launch
Panel discussion on security trends and needs
Panel discussion on cloud computing and enterprise architecture
Access the conference proceedings
General TOGAF 9 information
Introduction to TOGAF 9 whitepaper
Whitepaper on migrating from TOGAF 8.1.1 to version 9
TOGAF 9 certification information
TOGAF 9 Commercial Licensing program information
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect.
Today, we welcome our listeners to a sponsored podcast discussion coming to you from The Open Group’s 21st Enterprise Architecture Practitioners Conference in San Diego, Feb. 3, 2009. Our topic for this podcast, which is part of a series of podcasts on events and major topics of this conference, centers on TOGAF 9, the newly released enterprise architecture framework.
The framework, the latest in the series, was released here Feb. 2 at the conference, and it really represents a departure for The Open Group and for enterprise architecture frameworks in general. It's larger, more mature, and modular to allow folks to enter it from a variety of perspectives. It takes on a much more significant business services and accomplishments perspective.
While IT practitioners and architects will be looking over TOGAF 9 deeply, it’s also going to be of interest to the business side of the enterprise and will be a way for them to understand more about how IT can service their business needs.
To guide us through our discussion on the evolution of TOGAF 9, where it's come from and where it is today, we're joined by Robert Weisman, CEO and principal consultant for Build The Vision, based in Ottawa. Welcome to show, Robert.
Robert Weisman: Delighted to be here.
Gardner: We're also joined by Mike Turner, an enterprise architect at Capgemini, based in London. Welcome to the show.
Mike Turner: Thanks, Dana.
Gardner: It's been my contention for some time now that architecture is destiny. How well you do architecture has a deep impact on your cost, your benefits, your quality of services, and ultimately, how competitive and well run you are as an enterprise.
Let’s go first to Robert. Do you agree that architecture is destiny, and is it perhaps more so now than ever?
Weisman: I can see architecture being an integral part of the business planning process. It structures the business plans and makes sure that the objectives are realizable. In other words, we can use the acronym SMART, specific, measurable, actionable, realizable, and time bound. What TOGAF 9 does is provide an overarching vision and capability with which to cooperate.
Gardner: Let’s take the same question over to you, Mike, this notion that how well you do architecture is a rather important aspect of your competencies of business. [Read more on a panel discussion about the importance of enterprise architecture.]
Turner: Architecture is definitely a factor. I see architecture as a set of tools and techniques that can help you achieve what you want to do as a business. Taking architecture in isolation is not necessarily going to achieve the right things for your organization, because you actually need to have the direction as an input for architecture to support achievement of a particular outcome.
Architecture is really a vital tool for is being able to assure that the correct business outcome is achieved. You need to have a structured approach to how you define the problem space that businesses are facing, then define the solution space, and define how you move from where you are right now to where you want to be.
If that’s not managed in a structured and traceable way that takes you from strategy through to realization, it’s very easy to go off track. It’s very easy for people to reinterpret what the business needs. It's very easy for technology projects, in particular, to take on a life of their own and deliver something, but not necessarily the thing that was originally intended.
So, in some way, architecture is that essential toolkit to make sure that the achievement of change is realized effectively from a content perspective.
Gardner: Change, of course, is a very important aspect of business nowadays, with a difficult economic climate and rapid change across many different industries, how they finance themselves, what their customers are doing, as well as the supply chain. Before we get more deeply into TOGAF 9 and frameworks, what does architecture bring to the ability of an organization to change rapidly?
Mergers and acquisitions
Weisman: When you're talking about change in this climate, there's going to be a great many mergers and acquisitions. Having been through them, there are two ways of going through them -- painful and less painful. Architecture is certainly a less painful way of doing it.
If you want to use knowledge in a knowledge-based economy, you want to make sure, when you actually acquire a company, that they stay acquired, that they don’t just walk. You have to know what they have. You have to also know the value of the soft assets within a company, and that’s what architecture brings to the fore. It brings out clearly the full value of the company, and make sure, before you do an acquisition or a merger, that you can compare the companies and do due diligence to determine whether there is actually a fit.
Gardner: Mike Turner, how about this change aspect and how architecture might be a serious foundation for good change management?
Turner: That question would have a different answer depending on the type of change that you are looking and dealing with. There are some changes that organizations are prepared to encounter and are anticipating. In those cases, architecture is a really good tool to help you to become more effective at dealing with those changes as they happen.
A good example of that would be a large organization that’s on an acquisition trail of buying up small organizations that operate in a similar business model as they do. Using architecture as a technique, you can actually say, "When we acquire a business, we expect it to have these capabilities. This is how we would take those capabilities into our environment." You can quite quickly absorb that change by having a repeatable approach to deal with it.
In those kind of spaces, architecture is really key, because you're anticipating the change, can plan for it, and can manage it strategically. If you don’t do that, then you end up having to face the problem afresh every time you encounter this situation and become ineffective at dealing with those kinds of repeatable processes.
Gardner: What about the discipline that’s required through adoption of a framework, that then puts you in a position to be able to be fleet and agile, when the unanticipated changes are required?
Turner: The other class of change is the change that you weren’t expecting. In those situations, your organization needs to be structured or siloed in ways that actually allow you to quickly reorganize and do things that are unexpected.
In those kind of situations, there's a component where architecture is helpful and then there's a piece where a architecture probably isn’t going to help you at all, because you're dealing with something that’s outside of what you understand today.
Architecture can help you structure your organization so that it's flexible. Outside of that, you're really into the space of a more agile-type approach, where you're not prepared to deal with things, and you just need to try something out, do something quickly, do something tactical, and build from that.
Plan for change
Weisman: There's an old adage that a plan is a common basis for change. If you don’t have the plan or your architectural framework, change is very difficult. Secondly, there is the old Roman adage, which basically says that luck is only where opportunity meets preparation. Architecture is that preparation or part of the preparation for that.
Gardner: Let’s take a brief trip down memory lane. I spoke to Allen Brown, the CEO of The Open Group, and he said that 9 coming out was, in a sense, like giving birth. It was a long gestation period and then a rather difficult last few days. So now that its out, tell us what the frameworks were like leading up to TOGAF 9, and then particularly what differentiates or distinguishes 9. We'll start with you Robert.
Weisman: TOGAF 9, first of all, is more business focused. Before that it was definitely in the IT realm, and IT was essentially defined as hardware and software. The definition of IT in TOGAF 9 is the lifecycle management of information and related technology within an organization. It puts much more emphasis on the actual information, its access, presentation, and quality, so that it can provide not only transaction processing support, but analytical processing support for critical business decisions.
The gestation took five years. I've been part of the forum for five years working on the TOGAF 9. Part of the challenge was that we had such an incredible take up of TOGAF 8. Once a standard has been taken up, you can’t change it on a dime. You don’t want to change it on a dime, but you want to keep it dynamic, update it, and incorporate best practices. That would explain some of the gestation period. TOGAF 8 was very successful, and to get TOGAF 9 right, it was a little longer cycle, but I think it’s been well worth the wait.
Gardner: Mike, what more generally has been the shift or change over time in how frameworks have been developed? Obviously, they've gotten larger and are more inclusive, but more generally, as a character of what they're trying to accomplish, how have frameworks changed over the past 20 years?
Turner: If you look at the industry in general, we're going through a process where the IT industry is maturing and becoming more stable, and change is becoming more incremental in the industry. What you see in architecture frameworks is a cycle of discovery, invention, and then consolidation that follows, as consensus is reached.
One thing that’s really key about TOGAF 9 is that it takes a lot of ideas and practices that exist within individual organizations or proprietary frameworks, building a consensus around it, and releasing it into a public-domain context.
Once that happens, the value you can get from that approach increases exponentially. Now, you're not talking about going to one vendor and having to deal with one particular set of concepts, and then going to a different vendor and having to deal with another set of concepts, and dealing with the interoperability between those.
You're in a situation where the industry agrees this is the way to do things. Suddenly, the economies of scale that you can get from that, as all the participants in the industry starts to converge on that consensus, mean that you get a whole set of new opportunities about how you can use architecture.
Vendor and technology neutral
Gardner: For those listeners who might not be familiar, The Open Group is a vendor-neutral and technology-neutral consortium. TOGAF, which is The Open Group Architecture Framework, is free in its online form, and there's a charge for the printed version.
About 7,500 individuals currently hold TOGAF certification, which is another important aspect of TOGAF, basically approving that you have the knowledge, experience, and understanding to carry it through. To date, 90,000 copies of TOGAF framework have been downloaded and 20,000 hard copies have been sold.
Let’s go back to Robert Weisman. Let’s look a little deeper at what distinguishes TOGAF 9. We mentioned the modularity. There is also the deeper use of the architecture development method. There is also a bit more inclusive comfort, if you will, with cloud computing and service-oriented architecture (SOA), and thinking more of security, start to finish and holistically. Maybe we could go through a laundry list of what distinguishes TOGAF 9.
Weisman: There are many particular factors. TOGAF 9 is, in certain ways, an evolutionary change and in certain other ways a revolutionary change. The architecture development methodology has basically remained similar. However, transforming the architecture from concept into a reality has basically been expanded pretty dramatically, with a great many lessons learned. So, architecture transformation is a large one. Various architectural frameworks have been incorporated into it.
A great many concepts that allow enterprise architecture to be molded with operations management, with system design, portfolio management, business planning, and the Governance Institute's COBIT guidelines and other industry standards have also been incorporated into TOGAF.
Also, there's been a major contribution by such companies as Capgemini, with respect to artifacts and structure. The content meta model is a huge contribution and as a core contribution, but Mike can elaborate upon that.
Overall, it’s much more extensive and it covers much more of the issues that most CIOs and IT architects have to confront on a daily basis. The nice thing about TOGAF is that you don’t have to use it all. You can use bits of it. You can use a large chunk of it, or you can basically choose to use in its entirety. It’s a very modular and flexible framework that way.
Gardner: As I understand it, with 9 they have made a pathway. If you've already adopted 8, you have a bit of a head start, but you don’t have to have gone to 8 in order to start adopting 9. You can work through different modules and start fresh, which I think is a bit of a departure from the past.
Let’s go over to Mike at Capgemini. Tell us about the meta model, and particularly how the use of repositories for policy driven governance and for the organization of assets across both IT and business become relevant now. [More on how Capgemini views cloud computing.]
Addressing challenges
Turner: If we rewind to TOGAF 8 and talk about some of our experiences using TOGAF 8, that's probably a good way to frame what we've tried to add into TOGAF 9 to address some of those challenges that we have encountered.
TOGAF 8, in our experience, was a very powerful process that you could follow to develop architectures. Where you started to hit limitations with TOGAF 8 was around the work products that you produced as a part of executing the architecture development method.
So TOGAF 8 has a lot of language that talks quite informally about the type of activities that an architect would carry out and the type of work products that they would create.
For example, it discusses creating business scenarios and process models and looking at logical data models and physical data models. There's a lot of language in TOGAF 8 that refers to modeling concepts, but then there is nothing actually in TOGAF 8 that says, "This is what a good deliverable looks like," or "This is actually how you would approach modeling those concepts formally."
What we find are organizations that are using TOGAF 8 effectively have two choices. They can adopt the process and leave the content side of things quite open-ended, or they can adopt the process and select something else to do with the content.
At Capgemini, we had a proprietary internal framework for content prior to TOGAF 9. We did a lot of work taking TOGAF 8 process and Capgemini content framework and putting the two together. We found that to be a really effective combination.
What we also found was that, because of the proprietary nature of the Capgemini framework, it became quite difficult for organizations to adopt that configuration. While we're working entirely within a Capgemini environment and we've got control over the people, the skills, the knowledge, and the approach, that works really well. But, when you're looking at multi-vendor sourcing models or looking at upskilling an end user organization, it becomes a lot more difficult.
What we wanted to do with TOGAF 9 was to address that problem head on and to try to create something equivalent to the Capgemini proprietary framework in a way that allows incremental evolution out of TOGAF 8. We took a lot of the informal concepts that were defined in TOGAF 8 and tried to formalize those around some of our internal thinking for content.
Gardner: What is the upside now, since we've made this transition to 9, for the strategic use of repositories?
Turner: One of the things that we've been working on quite heavily over the past few years is getting the various tool vendors to support the Capgemini framework. We've got quite a long list of tool vendors supporting this framework model. What we are expecting is a small incremental effort for those same vendors to transition and make what are essentially cosmetic changes to be able to support the TOGAF 9 content framework.
Very soon, we'll be in a position where we're looking at a market for enterprise architecture tools, where there is now a level of consensus about how to structure models and how to represent them in a way that didn’t exist before. That can only be a good thing for enterprise repositories, because we're moving closer and closer to that consensus point about how content should be structured.
The problem that we're unable to solve is then to take that model, go one step further, and look at the actual operating model within a particular enterprise, how that enterprise chooses to assign roles and responsibilities for carrying out architecture, and how it chooses to federate governance and those kind of concerns. This is fundamental to how you structure repository, because the repository needs to reflect the partitioning that you actually hold within your organizational structure.
We'll see a big improvement, but it’s not the solution in its entirety.
Gardner: Repositories will include a number of different types of artifacts and services, and each organization will have a unique way of approaching that, given their legacy and their history. We do seem to have reached somewhat of a tipping point in recognizing that to manage complexity, to adopt SOA principles effectively and extend them holistically to start dabbling in cloud computing and take advantage of resources and assets available through that particular model or set of models. Does this increasingly require this organizational framework of repository. Do you agree with that Robert?
Underlying rigor
Weisman: No. I've been an enterprise architect now since 1985, and many of these terms come and go. Underlying it is a certain degree of rigor that the frameworks provide.
It doesn’t matter what environment you go into, but if you have a client with 500 definitions of client, their customers, and you're trying to integrate that to take an overview of the customer throughout goodness knows how many databases, what happens is there is certainly a cogent case for consolidating that.
Many organizations carry orders of magnitude more information than they need. The implications for the information technology infrastructure are immense, and the quality of information because of that is pitiful, not allowing the business executives to make proper decisions.
Whether you do cloud computing or not is immaterial. Whatever paradigm you choose, as long as you apply it in a professional and effective manner, it will work. Trying to use a silver-bullet type of approach and a new name to circumscribe rigorous engineering and professional principles would be a grave error.
Gardner: Okay, fair enough. What is it about TOGAF 9, in particular, that does grease the skids a bit for organizations to better adopt and utilize SOA principles, services like software-as-a-service (SaaS), or infrastructure-as-a-service, what we loosely call cloud nowadays?
Weisman: TOGAF was based on a foundational architecture called the Technical Reference Model, which came out of the U.S. many years ago. It's all service oriented.
The term SOA is old wine in new bottles. It's been around for a long time. If you just have a service catalog, if you have duplicate services, it becomes very evident. That’s one of the advantages of the repositories -- you can have an insight into what you actually have.
TOGAF, from its outset in the early 1990s, has been service oriented for that. Just by applying TOGAF, you have a chance of doing your Gap Analysis, of having the visibility into what you have, which makes it not only efficient, but effective from a business perspective.
Gardner: Anything to offer, Mike?
Two points of view
Turner: When you look at SOA, there are probably two different ways that you can think about IT. One offers quite limited benefits to an organization, and the other offers much greater benefit. At a technical level, there are a bunch of standards and design approaches referred to as SOA, that really deal with standardizing the way the applications talk to one another at a software level.
Implementing SOA in this technical sense isn't necessarily a bad thing, and there are certainly benefits to be had in terms of interoperability at a software level from implementing SOA principles. But, just working at that level on its own is not going to give you any business advantages. It’s just going to make it easier to execute development projects.
The power of thinking about services is much more centered on how you look at your organizational capability and how you can more effectively break down your organization into discrete capabilities that are not replicating the same data, business processes, and IT systems in multiple silos.
If you can have a more granular business organization, where you are replicating capability less, it’s much easier to change more quickly, it’s much easier to use those capabilities to do different things, and you see a step change in the performance of your business.
We need to get those kinds of SOA benefits. The first and most important question to ask is, "What are the services that I need in my business? How should I structure my business to make it meet the goals of the industry?" That may be flexibility, but there are actually some organizations or some parts of your enterprise where you actually don’t desire flexibility. You want stability, cost efficiency, and effectiveness in a much more linear, repeatable sense.
TOGAF allows you to understand what makes your business good and then identify what your services are in a way that considers all the different angles. Once that’s defined, you can then put the right technology underneath that to realize what the business is actually looking for. That’s something that can have an absolutely transformational effect on your business.
Gardner: You mentioned that architecture and SOA by themselves don't necessarily aid a business in achieving its goals, but TOGAF 9 has taken steps over this past five years to increase its relevance to business. Robert, explain how that takes place and what that really means?
Weisman: We're talking about services here. The old TOGAF used to talk in terms of the Technical Reference Model. That's still in 9, but we're looking at business services, as Mike was alluding to. We're looking at rationalizing business services and making sure that they're basically well supported by that.
It also assumes that, when you're doing your preliminary planning, you come up with a framework that recognizes the business operation model within your organization and that you have identified your stakeholders and what they actually want to see in the enterprise architecture framework.
Lack of vision
Most projects fail, because they don’t have proper preliminary planning, and they don’t basically go through the problem. They don’t go through the effort of putting a vision in place. As a consequence, they just jump into the architecture -- usually into the applications and technology architecture -- and they find themselves in trouble very quickly for that. They get a great deal of dissatisfaction.
Outsourcing is an excellent example where a high degree of enterprise architecture maturity correlates to a high degree of satisfaction from both the client and vendor of outsourcing services.
Satisfaction, according to Peter Weill’s book, Enterprise Architecture as Strategy, essentially goes from 50-50 with poorer enterprise architecture maturity to 90-90 with enterprise architecture maturity, and that’s satisfaction both for a client and vendor.
So it ends up being a win-win.
When I talk about outsourced services, they are not necessarily all technology either. They can be business processes that are now being outsourced as well, and it will work its way up the stack.
Gardner: We've talked about architecture as important, of course, but the people who then implement the architecture are quite important. To what degree is certification now a particularly relevant aspect of success in a down economy?
Labor issues and getting good people have been a challenge. There have been significant layoffs, but there has also been an increase in the demand for strong IT to support change in a dynamic business environment. Let’s start with you Robert, the role of certification in the year 2009?
Weisman: First of all, there are two dimensions of certification. For example in The Open Group, you have certification with respect to knowledge of the TOGAF methodology, and then you have IT architecture certification. IT architecture is much broader. It includes business architects and enterprise architects as well, and that takes a look at competencies.
There are no international standards for IT architecture. There are many consultancies that work globally. So, all of a sudden, you're called upon, but this provide a global standard and a global level of confidence with respect to the individuals.
The IT Architect Certification (ITAC) and the IT Services Certification (ITSC) that The Open Group are doing, will provide a level of comfort and assurance to clients that basically they are getting people with a uniform degree of competence.
With respect to the downturn, this is going to become important. Right now, most architects call themselves architects, but there is no international standard against which to measure them. That’s led to a great many architecture failures, which, when you examine them, are not surprising.
Using a standard methodology will also enable RFPs to be written rapidly. What happens is now when you say, "I want a vision as per TOGAF," everybody knows what the baseline is. Then, both suppliers and clients can come up with the assurance, saying, "These guys know what they're talking about," and they can put in a reasonable bid for that.
You're talking about the standardization of product and competencies. This is becoming increasingly important. Globally, there's a huge decrease in enrollment in computer science and computer engineering programs, because of the fact that clients aren’t recognizing these professional designations. Many people say there's no business case in going through an expensive degree program, when you can take a short course and have a very deep but very narrow competency in a particular field?
Certification, both from a competency point of view and from a product point of view, is the wave of the future and extremely important.
Gardner: Mike, how does Capgemini look at the certification process and how important it is for your clients?
Demonstrating capability
Turner: It’s very important, and there are two reasons why. If you look externally in trying to source resources from the market -- whether that’s through a subcontractor or to recruit individuals -- having certification is a good way for candidates to be able to demonstrate that they have reached a level of capability and also for potential employers to put in place a benchmark that filters out the noise.
They can spend much more time looking at individual candidates and assessing them as potential fits to the roles that they're trying to source. I wouldn’t say that certification necessarily guarantees that you get the right person, but it gets you to a short list much quicker.
Gardner: How about practitioners themselves? Is there a significant boost in the pay or ability to find the right jobs as a result of this TOGAF certification?
Turner: If you look at the UK market, there is a correlation between certification and higher pay, but I wouldn’t that that’s the absolute overriding factor.
Another angle to this is, if you look within an organization -- and Capgemini as an organization has a large number of architects, but our client base has architects that work in their organizations -- certification starts to outline a career path for architects within an organization and to allow them to develop themselves and demonstrate that they are improving in capability.
Capgemini has a very active certification program, which we run internally and which is based on experience, engagement, and community. We find that to be a very effective way to build and maintain a community and show professional development and mentoring within our internal environment. That’s something that we help our clients do as well.
Ultimately, architecture is about a network of people. It's about communicating effectively within that network, and then that network having a good face to all the stakeholders for architecture. Having training certification, professional development, and those factors can only be a good thing for building that practice.
Gardner: We're going to be wrapping up in a bit. It’s clearly too soon to look into the future. We just got TOGAF 9 out of the gate. I wonder if there isn’t any extrapolation or looking from the vision point of view where we have come from TOGAF 8 to TOGAF 9, to perhaps give some indication to our listeners as to where TOGAF and enterprise architecture frameworks in general are headed.
Let’s start with you, Robert, for our last question. What can we say, given what we now know about TOGAF 9, as to where the next TOGAF might lead us?
Weisman: There are many working groups right now working on TOGAF, the next generation, whatever it’s going to be called, for example, the Information Architecture Working Group and the like. They've been established and they're looking towards the future and the strategy for that.
Working together
What I see eventually is a lot of these architectural frameworks will start emerging. One of the beauties of TOGAF is that it works very well in conjunction with other architectural frameworks. Let’s say that you're using another architectural framework, which a lot of the industry verticals have. Normally they're model based and TOGAF is mainly process based. They come together, extremely well together, and this is a major strength.
You can’t say, "I'm using this. I can’t use TOGAF." TOGAF will help you deliver the other framework. One of the major issues with many of the other frameworks is that they're wonderfully detailed models, but there is no methodology in place with which to deliver them in a systematic manner. So, I see TOGAF not in terms of an über framework, but certainly a cooperative framework.
It’s also linked with other management frameworks and it’s going to be closer to project management, portfolio management, and the like, which should make it an easier transition. An integrative framework of choice might be a way of describing where TOGAF is going. It's going to be a pointer to other standards and how to integrate them within a company.
We're not there to duplicate the work of other wonderful organizations. It’s how to integrate all the wonderful work, because right now, for executives at the CIO and CEO level, it’s pretty confusing out there.
Gardner: Mike Turner, do you agree on that particular extrapolation in the future of more inclusivity and convergence across business types of frameworks, or are there other future elements of TOGAF we should consider?
Turner: Those are all valid points, and I'd add a few more. One thing we're going to see with TOGAF 9 being available now in the industry is that there would be a reaction to that. A lot of the frameworks and standards that sit around the edge of TOGAF are going to realign slightly to make themselves more consistent with how TOGAF works, which, as Bob mentioned, will help TOGAF integrate some of these different approaches. That will happen without changing TOGAF itself. It would just be that the industry will change to be more aligned around the TOGAF model.
In terms of TOGAF development, there's going to be a big focus on people and organizational aspects within TOGAF, trying to formalize the different skills that are required and the different places where you can use TOGAF within an organization.
Ultimately, that will lead to much greater specialization of the method that we have right now, because we have a single method that applies at a very strategic level and also at a very tactical level. As we understand the organizational context, we can start to be more specific about how the method is applied in different contexts.
Another trend is around the formalization of the specification content. We would expect to see, particularly around a standard for managing this kind of massive information that you are managing semantic content and mature, that TOGAF will start to embrace some of those standards. Looking at formal languages for specifying the methodology and putting the tool set itself within software tools that can be customized and configured is something that we would look to do.
Gardner: Well, that gives us quite a bit to look forward to, some more maturity, even though we have reached a significant milestone in the current level of maturity.
We have been talking about TOGAF 9, its introduction and where its come from and part of its evolution. Our conversation today comes to you through the support of The Open Group, and we are coming to you from the 21st Enterprise Architecture Practitioners Conference in San Diego, in February 2009.
I want to thank our panelists. We have been joined by Robert Weisman, CEO and principal consultant for Build The Vision. Thank you Robert.
Weisman: You're very welcome.
Gardner: Also Mike Turner, enterprise architect at Capgemini. Thanks so much, Mike.
Turner: Thanks.
Gardner: I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to BriefingsDirect. Thanks and come back next time.
Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: The Open Group.
Transcript of a podcast on the development of the TOGAF 9 architectural framework, announced at The Open Group's 21st Enterprise Architecture Practitioners Conference in San Diego, February 2009. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
View more podcasts and resources from The Open Group's recent conferences and TOGAF 9 launch:
The Open Group's CEO Allen Brown interview
Live panel discussion on enterprise architecture trends
Reporting on the TOGAF 9 launch
Panel discussion on security trends and needs
Panel discussion on cloud computing and enterprise architecture
Access the conference proceedings
General TOGAF 9 information
Introduction to TOGAF 9 whitepaper
Whitepaper on migrating from TOGAF 8.1.1 to version 9
TOGAF 9 certification information
TOGAF 9 Commercial Licensing program information
Subscribe to:
Posts (Atom)
