> Archive > Issue XII: November 2007 > SOA Pioneers Interview Series Intel Chief Architect Steve Birkel on SOA Practices and Intel's SOA Adoption
Steve Birkel

Steve Birkel


Steve Birkel is the Chief Technical Architect for Intel's Information Technology, where he leads development of technical infrastructure strategy and enterprise integration.

He was instrumental in establishing Intel as a leader in Internet e-Business: his team established the technology backbone for Intel's Web presence and e-Customer and e-Supplier capabilities. He has been with Intel for the past thirteen years.


rss  subscribe to this author


SOA Pioneers Interview Series Intel Chief Architect Steve Birkel on SOA Practices and Intel's SOA Adoption

Published: November 6th, 2007 • SOA Magazine Issue XII

Abstract: Intel recently moved from a multi-year SOA pilot project to a larger-scale SOA adoption initiative. In an exclusive interview with The SOA Magazine, Intel Chief Technology Architect and SOA Author Steve Birkel discusses the challenges and lessons learned and explains some of the approaches used by Intel IT to achieve high levels of ROI through repeated reuse. Steve further reveals Intel's strategic SOA vision and how the SOA movement has even influenced the manner in which Intel is designing the next generation of its microprocessors.

SOA Magazine Let's start with your upcoming book "SOA Demystified" [REF-1]. One thing I did not get from reading the description is whether the book documents SOA projects that have been carried out within Intel.

Steve Birkel: Yeah, only indirectly, however. It doesn't take the literal sidebar type case study approach. What we have done is pretty much integrate that stuff into the content of the book to substantiate some of the claims we make. And, by the way, Intel gets no more focus in terms of Intel's SOA programs than any other companies that we talked to, some in the government sector, telecom sector, others in the manufacturing sector; Intel is treated as a manufacturing company. So, you will see Intel in the manufacturing sector as one of several sectors with a chapter devoted to each, and then identifying essentially the challenges [and] the opportunities that are common in that sector with respect to implementing SOA.

SOA Magazine: So, as a manufacturing company that's been actively building services, what's your overall opinion of SOA and how well do you feel it has evolved so far?

"To be ultimately successful with SOA, I think an organization has to make substantial changes to the lifecycle because the [traditional] lifecycle is designed for that vertical integrated solution delivery mechanism and all the planning that surrounds that."

Steve Birkel: From an Intel internal perspective, we see an increasing amount of benefit emerging [from SOA]. The evolution seems to be more in terms of interoperability and the real promise of interoperability going forward between different off-the-shelf providers of services and the ability to plug into a framework that would allow those services to interoperate seamlessly without a huge amount of integration overhead.

When Intel looked at the amount of resources we were putting into pre-SOA integration - point-to-point types of integration - we were really spending an inordinate amount of our development capacity in both developing and then sustaining those integrations as vendors would change their products. And so, instinctively, there was the appeal of SOA that came to light. We used several large enterprise vendors, but I can't name them. These vendors were all offering parts of their capabilities through suites of services, but [we found that] none easily interoperated.

It seems like the big thing that is happening now in terms of maturing SOA is that this level of interoperability is becoming much more real. Where we would put a huge amount of development resources into point-to-point integration before, we still saw a significant amount of investment required to make even the [early] SOA out-of-the-box components interoperate. Now, we are seeing that become less as the situation matures and we have vendors that are offering products which much more directly enable that interoperability.

SOA Magazine: For how long has Intel been building services?

Steve Birkel:We started SOA proof-of-concepts at Intel back in 2004 when we first began to experiment in a very serious way. These proof of concepts were really developing the business case to say, if we go down the path of SOA, we would get a substantial amount of ROI out of it, and then basically prove our assertions through some technology and business process integrations. That started in 2004 and continued in 2005. It didn't really get out of the lab from a project standpoint and get blessed as a mainstream effort until late 2005. We spent the better part of that year developing a proto-integration framework and methodology along with a set of SOA development practices that we would basically [use to] coach our development teams and the teams that were integrating some of the off-the-shelf products into this framework. We spent about a year developing that in terms of the baseline services for doing the really basic SOA functions as well as the integration capability, the bus, if you will... Then, after about a year, we also began to develop and deploy some higher level business services that were able to be consumed and reused.

SOA Magazine: And how well did those early pilot projects work out?

Steve Birkel:It has gone pretty well. We also developed a Services Portfolio Planning Process that was really a business process around how you identify services and prioritize service delivery and publication within Intel, and makes you kind of go through a rigorous process of sizing up and proactively identifying their value. [As part of this] we were also planning to intercept some of the business solution projects they employ so that those services arrive in time, which we found out is one of the most difficult things about SOA - taking groups that previously had been pretty much focused on discrete vertical solution, integration, and development, and getting them to discus with you how they can decompose many of those into common services and then agree on what the highest value, highest priority services were. These were all new conversations [for us].

SOA Magazine: So that must have then somewhat impacted your IT culture and your overall project delivery lifecycle. Did you have to make significant changes to how you delivered solutions?

Steve Birkel:To be ultimately successful with SOA, I think an organization has to make substantial changes to the lifecycle because the [traditional] lifecycle is designed for that vertical integrated solution delivery mechanism and all of the planning surrounds that. Right now, the place we are at with SOA is [that it represents] a benefit that our teams are seeing as: "Okay, we don't have to develop that piece because it fits into a regular lifecycle as a pre-composed modular piece of the project that we otherwise would have had to discretely develop".

It sounds kind of odd, but I think when you are in the early stages of [SOA adoption], which I think Intel still is, you will tend to look at the value-add of SOA as a benefit to your existing project efforts as opposed to [something that can] revamp your entire development process. I think that this broader view comes over time because as the value begins to accumulate, the organization would kind of tune itself to more and more services and less and less custom development of capabilities.

SOA Magazine: From the services you have delivered so far and from them being active for a period of time, have you had enough time to measure any return on your initial investment? Or, is it still too early?

Steve Birkel:We have. I think that is one of the things that we felt we had to do - get a balance between what investment we put into creating a service and then [keep track of how] it was reused, even a few times with a few projects. It was the balance required between investment in the service versus the return, and we have been able to do that. We did some calculations and identified a tipping point between the number of instances of reuse you get out of a service before you are likely to see a positive ROI for the effort that went into it.

SOA Magazine: Organizations accustomed to delivering standalone applications have traditionally found reuse challenging because it requires a design approach that runs contrary to silo-based application design. How difficult was it for your project teams to start taking reuse into consideration?

"We have actually measured reuse at Intel in quite a substantial amount. I don't think I can give you a specific number, but [it is] in excess of tens of millions of dollars worth of reuse value."

Steve Birkel: Well, maybe I should put this in a slightly different context. We have actually been very focused on reuse for a number of years, and reuse in SOA is easy because you save every time you re-utilize the service in the process of developing a solution. In the past, we had code reuse; basically we had chunks of code that were functionally complete in some way, much in the same way you look at a "service", and we had a library of those functions that were available for reuse, and we were actually tabulating that over the last several years, and we have actually seen quite an increase in reuse. So, we were benefiting from the fact that developers were increasingly accustomed to thinking about reuse first and doing custom development second.

So, SOA actually ended up being "SOA Services Development", and consumption ended up being a very natural extension of that concept of reuse. We have actually measured reuse at Intel in quite a substantial amount. I don't think I can give you the specific number, but [it is] in excess of tens of millions of dollars worth of reuse value.

SOA Magazine: Can you tell me more about the specific design approach or methodology that Intel used and do you see commonality with mainstream design approaches?

Steve Birkel: I think that the mainstream approach in [Erl's] SOA Principles book [REF-2] and the methodology that our team developed kind of take into account that 'an ounce of prevention is worth a pound of cure', and really the more upfront work you do in terms of defining taxonomy, in terms of identifying and preparing your development community to make really effective use, the much more effective your deployment is going to be. This has been quite clear to us and I actually am quite proud of the work that the team did. But when we first started, we probably spent more time identifying our direction than in retrospect I wish we would have, but that was because we were still learning. [We were asking ourselves:] What are the really truly important aspects of service design? What are the services that are "must haves" before you can begin effectively publishing them, and so on. And it took us a while to get to that.

I would say, it took us probably six months to get to the point where we had really formed a very solid understanding of what [SOA within Intel] needs to be and then we spent another six months developing that along with the practices that would be handed off to the developers. So, we ended up [producing] a very rigorous set of recommendations and design roles that the developer community could pick up and use, and I think that is serving us very well. After being part of the review [of Erl's book], we found that our practices did parallel a lot of the design principles in the book. I actually wish we would have had that book when we started the project. To be quite honest, I think it would have saved us some of the discovery that I think a lot of organizations have had to go through...

SOA Magazine: What do you mean by "discovery"?

Steve Birkel: Discovery coming from the custom integration, custom development standpoint, and then figuring out why some of these principles are important, and why doing things in a certain way is so highly recommended.

SOA Magazine: In the early days, there was an absence of published resources. So, if an organization interested in SOA did not go through this type of discovery process it could easily misinterpret SOA or make mistakes in terms of defining service-oriented architecture as an architectural style and then service-orientation as its associated design approach. There was so much ambiguity floating around the media and vendor literature that ultimately led to disappointment because the path to achieving those expectations was never clear. The most common example of this was the wide-spread assumption that the use of Web services constituted an SOA. Have you seen this as well?

"Right now, we still have a very substantial number of project managers and software developers at Intel that are tasked to bring out custum software and a few folks that are working common services.

Five years from now, I would like to see that almost flip over and I would like to see a significant pool of solutions used by our solutions."

Steve Birkel: Yes, exactly. That actually, if I could reflect back on earlier in answer to your evolution question, I think right now our Intel IT Senior Management really does understand the benefit of the modular approach of SOA and the reusable nature of well-designed services, and what they hear is many of the strategic vendors for Intel are offering services in one way or the other. And because of, as you mentioned, because if you have varying approaches to the way you implement services, we have found that it is not as though you can readily connect the services from one vendor into the portfolio of another.

I think that is the thing... if you custom develop and custom design it all yourself, you are going to probably have a fantastic portfolio of services, but for us, that would require way more resources than we want [to commit]. We want to take some of these off-the-shelf capabilities and services and apply them to our environment.

SOA Magazine: I realize you haven't yet achieved an enterprise-wide SOA, but with regards to scope, would you say that your SOA initiative is being implemented within a meaningful segment of the Intel IT enterprise?

Steve Birkel: Yeah. We basically are [establishing the] foundation right now, doing some very foundational services in support of some of the IT business customers. For example, we look [at] applications under development right now, and try to identify and factor out services. We are really trying to see where the greatest business benefit would be, and these are really, really fundamental services that are being published. For example, services that relate to customer lists or employee information, because that [type of functionality] ends up being pulled from a great number of the applications.

SOA Magazine: Is this one project or are there a series of related projects that are all tied to an overarching SOA initiative?

Steve Birkel: It is the latter.

SOA Magazine: In terms of what you have experienced so far and all the phases you have been through with your teams, if you had to rank them, what would be the top three challenges you faced and perhaps the associated lessons learned? What advice do you have for others who are just starting out with SOA?

Steve Birkel: Well, I would certainly say that there is a tendency to want to go out and custom-design and fabricate your SOA implementation to a large degree. I think, honestly, [Erl's] book is an example of pulling industry's best practices into one resource and I would let that form your initial approach to accelerate some of the work you need to do to reduce the amount of time you waste on going down paths that end up leaving you in the position where you are forced to do it over again. Some of this is human nature I guess. You will have to go through [it], you have to make some mistakes before you are going to get there. I think that pulling in some industry's best practices is important now that they are becoming more available.

SOA Magazine: Okay, let's consider "using industry best practices" as recommendation number one.

Steve Birkel: I guess number two is to look at the broader horizon than the vendors and suppliers you are already used to. I mean, Intel now uses a set of suppliers that serve most of its IT software needs and we would look to those vendors first. But while that would normally be a logical thing to do, your current vendors are not necessarily the ones that you would look to for everything [you need] for SOA. Using industry best practices and looking to other companies and peers in the industry who are also going down the path of SOA is just common sense, and there is a lot to be learned from your community of peers.

SOA Magazine: Right, so exploring new vendor options would be your second recommendation.

Steve Birkel: And I think, you know what, I guess the third thing is do not get hung up on the technology to begin with. [SOA] is really not about technology because you can make almost any technology fit into a framework that is well designed. It really is about the practice, the processes, the portfolio planning, and change... It is the transition of change management within your IT that is really going to make or break your SOA. It is really not that much about the technology.

SOA Magazine: But speaking of vendor options and technology, how would you assess the overall maturity of the vendors' SOA platforms today in terms of your requirements and the target environment that you would like to realize within Intel? Are they halfway there? Are they close to providing what you need, or is there still quite a ways to go?

Steve Birkel: In terms of off-the-shelf type of SOA functionality?

SOA Magazine: Yeah, I guess in terms of development tools and runtime platforms and service-activity management and governance platforms; has a lack of maturity or a lack of sophistication in the technology and the tools held you back in your projects? Are you waiting for certain things to settle down so that you can invest more and build more, or has it not been a factor?

" SOA gains prominence, and it has, but as it gains more prominence, I think you will see more and more Intel optimization of systems architecture in order to accelerate SOA..."

Steve Birkel: I think the pace of the industry can slow you down substantially. There are some fine capabilities out there with respect to, as you mentioned, governance, management, which you discover very quickly you need.

Another interesting aspect is that when you are in the mode of developing self-contained applications, management and performance are issues your users will tell you about. Not so with SOA; there is this really subtle, but very important aspect of service management. Not to mention the lifecycle management, which is a whole other discussion.

However, I would say that it has not held us back because we are not in a state of maturity in our implementation where some of that stuff has become hugely impactful. Yet, I see it coming soon and we believe we have identified some of the preferred ways we will deal with governance and management and those type of things, and security. But when you have a relatively small implementation, you can do some really good things to prove the capability of SOA, while not yet meeting the more stringent controls that those capabilities would demand. And, as I said, it has less to do with any technology barriers or even barriers with respect to the availability of these more mature system capabilities. SOA has more to do with resistance to change or transition change management in an organization; getting people to think differently.

SOA Magazine: Has it been difficult for some groups within Intel IT to appreciate or comprehend the rationale behind some of the change they are being asked to adapt to in support of SOA?

Steve Birkel: I think everyone can, at an intellectual level, rationalize that SOA makes sense. But, there is a huge amount of promise and the gap is always that serious projects demand a certain amount of focus and attention on solving immediate problems. So what you have to be able to do is peel off some amount of that focus and attention that you are putting into the lifecycle of those solutions and put it into, if you will, kind of a pool of capability development that will provide you with services that are common. The missing piece in that has really been an agreement on how to approach the "portfolio process", let us say. For example, which services come first, where are the resources for those services going to come from, and how, actually, are we going to allocate those resources to [deliver the common services].

So I think everybody can pretty much buy into the concept that SOA has a tremendous amount of goodness, but what we have a difficult time doing is the 'how, organization-wise do we achieve this?".

SOA Magazine: I am not sure how you are structured in terms of funding, but did you have to go through an education process to bring those who approve projects on board?

Steve Birkel: Oh yes, in fact, that full year of proof-of-concept projects was exactly focused on that. The SOA proof-of-concept that I talked about earlier (that was done between 2004 and 2005) was a set of efforts that were invested in by our architecture organization that was done in collaboration with many of the business stakeholders. It was very much designed to produce data that would substantiate the claims that if we were to invest in SOA, we can expect some fairly significant returns. Once we got to the point where there was a fair agreement that this has a lot of potential and the data was there to support it, it was at that point that we went into the process of developing our SOA ecosystem, which took us another year or so before we developed our framework for service inter-connectivity.

SOA Magazine: This next question is something I like to ask any organization that is actively carrying out an SOA project in order to get a better sense of their long-term vision: Where do you see your SOA initiative leading you in five years from now? In other words, what does service-oriented architecture look like at Intel IT in 2012?

"It is the transition of change management within your IT that is really going to make or break your SOA.

It is really not that much about the technoligy."

Steve Birkel: Right now, we still have a very substantial number of project managers and software developers at Intel that are tasked to bring out custom software and a few folks that are working on common services. Five years from now, I would like to see that almost flip over and I would like to see a significant pool of services used by our solutions. It is something that does not really exist today, but [I want to see] a framework for producing a solution that basically consumes multiple services and assembles business critical services, practically on the fly.

After requirements are defined, it takes relatively little amount of time, and you need also less project management because those projects are much shorter in duration. You are able to produce custom business solutions (and map your automation to changes in business processes) very rapidly. Again, today, it takes many months to create a business solution the way we approach development. Five years from now, I would like it to be a relatively short process that is really optimized around the assembly of those services into solutions. I really think that we could be very, very far down that road.

And, I also think that another piece of the five-year picture is talking to our vendors about the services that they offer as opposed to their out-of-the-box software solutions. I want that conversation to shift so that it is very clearly about the constituent pieces of our services environment that they would provide for us.

SOA Magazine: Okay, one last question. You can tell me if I am treading on confidentiality here, but would you say that SOA itself is affecting how Intel is manufacturing its microprocessors?

Steve Birkel: Yeah, we have actually utilized many of the Intel developed capabilities internally in our exploratory efforts and a very exciting thing is going on with respect to XML compression, security, those kinds of things. From an Intel standpoint, I would see these additional capabilities that Intel platforms will provide to the marketplace, if you will, a lot of "SOA helpers" with respect to how clients and servers process SOA-related information.

SOA Magazine: So, would you say that it is an accurate statement that the SOA movement itself has influenced how Intel approaches the design of the products it manufactures?

Steve Birkel: Yeah. I do not want to overemphasize that, but I would say that there is a definite discernible impact. I have seen it in some areas and I expect as SOA grows in prominence, more and more... look at this way: Intel is in the business of optimizing systems for our customers because we know the more optimized they are for the uses our customers have, the more readily adopted Intel systems would be. So, as SOA gains prominence, and it has, but as it gains more prominence, I think you will see more Intel optimization of systems architecture in order to accelerate SOA, and usually it amounts to stuff at the lower levels from an Intel standpoint around like for example, security, acceleration, routing and these types of things...

SOA Magazine: Thanks so much.

Steve Birkel: Thank you.


[REF-1] "SOA Demystified", Girish Juneja, Blake Dournaee, Joe Natoli and Steve Birkel, Intel Press (ISBN: 1934053023)

[REF-2] "SOA: Principles of Service Design", Thomas Erl, Prentice Hall/PearsonPTR (ISBN: 0132344823).