We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Transformation in Action

Joe McKendrick

Transcript: Challenges and Opportunities in SOA and Cloud: Lessons Learned

Vote 0 Votes

The following is a full transcript from the session on "Challenges and Opportunities in SOA and Cloud:  Lessons Learned", part of ebizQ's Cloud QCamp. This session featured Phil Wainewright, well-known industry guru and ebizQ's Connected Web manager, who was joined by David Bressler, principal architect with Progress Software, Ed Horst, vice president of product strategy for AmberPoint, and myself.

Listen to the 45-minute interactive panel discussion here.

Phil Wainewright: Welcome to the first of our two live panel discussion sessions here today.  And this is all part of our Cloud QCamp online event here at ebizQ.  I'm Phil Wainewright, industry analyst with Procullux Ventures and community manager for Leveraging the Connected Web at ebizQ.  Our discussion today is all about Challenges and Opportunities in SOA and Cloud:  Lessons Learned.  

Really, this is a chance for us to chew over some of the ideas already raised in our two Webinars earlier today with our guests and I'd like to introduce them now.  So first of all, we have Joe McKendrick who's Contributing Editor and Analyst also at ebizQ.  Joe, welcome.

Joe McKendrick:  Hi Phil, glad to be here.

Phil Wainewright:  Well Joe that was great talking of you to keynoting our QCamp event today with that opening Webinar on SOA Meets the Cloud. And I was listening you present some very interesting ideas there some of which were, I think, much more "fully baked ideas" than you made out.

Joe McKendrick:   Thanks Phil.

Phil Wainewright: We also have David Bressler who is Actional Product Evangelist at Progress Software.  Welcome David.

David Bressler:  Thank you Phil.

Phil Wainewright: David I think you're in fine form too on our opening Webinar session and I think already looking forward to our discussion now, so welcome.

David Bressler: Thank you.

Phil Wainewright:  And finally a big hello to Ed Horst who is Vice President of Product Strategy at AmberPoint who joins us for this discussion.  Welcome Ed.

Ed Horst:  Thanks, nice to be here Phil.

Phil Wainewright:  And I just like to point out that AmberPoint and Progress Software are sponsors of today's discussion so thank you for your support and your participation. Now, let's dig into this topic and let's start off at first base I think I mean.  Obviously, there are lots of definitions of cloud out there and we're talking about the relationship with cloud to SOA so let's start with some definitions.  How do you -- each of you define cloud and what do you think of the key differentiations if any from SOA or server.  Joe, I think you talked about this a little in your presentation, didn't you so let's revisit that for a second.

Joe McKendrick: Okay.  Sure, Phil.  Well, actually it's just been amazing the past year or so how these concepts are converging or coming together and I'm talking about SOA and cloud in particular.  SOA is something that's been around since the beginning of the decade and a lot of companies have been working with it.  We've been seeing a lot of success stories and there's been a lot of struggle and a lot of discussion around what SOA is, what it means, what it should deliver, how you measure it and so forth.  And now, we're seeing a lot of this emphasis shift to the cloud.  

Now, just to kind of put it kind of simply, I think the main way you can distinguish between the two is SOA is the architecture, SOA is the underlying architecture, the way you build, maintain, govern, and orchestrate the services you deliver.  And the cloud is the technology, the vehicle by which these services are delivered from party to party.  But I think, it's getting to the point where you're not going to have one without the other.  If you're talking about SOA within an organization, you're also going to be talking about private cloud, internal cloud.  If you're talking about cloud computing, you're going to have Service Oriented Architecture or SOA principles behind the way the cloud is structured and delivered.

Phil Wainewright:  So Ed, let me bring you in there.  Is it as simple as that, cloud is just SOA but kind if implemented in some kind of Web-oriented way?

Ed Horst:  I guess define cloud based on the way our customers define it or use the terminology and they generally if they're using cloud terminology and interacting with AmberPoint, it generally is -- there's also an element of an external user that's part of that architecture or use pattern.  In other words, they're servicing some external either business partner or in fact end users in that fashion.  If it's all used internally, sometimes that's labelled cloud but often times its not, that label isn't used quite so liberally there.  

The other one say is -- the other two elements I see pretty common is there's an API expectation there or implementation.  There's an API that somebody can get their hands onto a business partner.  And then also, this kind of dynamic scaling of resources I think is  a common expectation as they're building cloud-based applications or something they would call a cloud based application.

Phil Wainewright: Okay.  Great.  So David, let me pass the ball to you there.  So I think we said that it -- there is SOA there but it's kind of Web-related that it tends to involve some kind of Web-based assets and it's got elements of scaling up and down to it, some kind of utility notion as well.  And tied into that there's going to be some kind of API structure.  Is that how cloud differs from SOA?

David Bressler: No, I don't' think that's essentially how cloud differs from SOA.  I think -- I like the way Joe said it at the beginning where cloud really is implementation of SOA.  To me, that kind of sums it up really nicely.  I think that cloud computing is a lot of things to a lot of people because we're all coming at it from different directions.  But from my direction, I believe it's a way to make integration much more easy and therefore deliver IT benefits.  Of course, these are the user benefits, but deliver benefits of IT to those users much more quickly, much more rapidly.

Phil Wainewright:  But I thought that was what SOA --

David Bressler: And how that happens --

Phil Wainewright:  But David, I thought that was what SOA was supposed to do.  I mean we're five years on from that vision so surely cloud brings something to the party.

David Bressler: But this does it through a way that allows you to use external providers to jumpstart that.  And by using external -- or have external as I'd mentioned or have external consumers using something that you've created, just depends on your perspective.  They're two sides of the same perspective.  But by doing that, it becomes much more component driven.  One of the things that happens inside an enterprise is a lot of the important infrastructure is discounted because there's no clear or immediate benefit.  

We can do this today.  Take security for example, you can fall back -- this was on my mind from the earlier of keynote discussion.  But you can fall back onto network level security when you own the whole stack and then do application level security later.  Network level security is something that's well known, its well established, everybody's comfortable it, put it into Phase II.  But as you start to work with the cloud provider, you are forced to secure your data at the data level.  And then were forced to actually implement service-level agreements and then be able monitor and manage those service level agreements as agreements that matter and are meaningful to a business that are tracked in real time, all the time, all those things.

And this is driven by the way that cloud is implemented.  I think they both have the same benefits because they both are essentially -- fundamentally, architecturally, they're both the same thing.  But that's where SOA leaves it.  SOA leaves it as an architecture, as a concept where cloud says, okay, we are now going to take -- and yes, there would be arguments about private clouds and stuff like that but cloud really is -- where one way to look at it is cloud is about external providers providing services and wrapping those (Inaudible) things including the contract, including the SLA, including whatever and then delivering that to different constituents.  

Phil Wainewright:  Right.  And actually sometimes, I jokingly or perhaps provocatively describe cloud as SOA done right.  And what I mean by that is because it's an open environment and you don't know who're interacting with.  You have to do all the service level things, you have to define the contract (Inaudible), you have to define your security requirements, you have to do all of those things you didn't necessarily bother to do in a controlled enterprise environment because it was controlled, because you knew what was going on.  You could look inside the services  at the other end of the transaction because you were the governing body and in the cloud, you have to have much more of a loosely coupled approach, I think.  I mean, Joe, what do you think?  Does that get us closer to the key differentiation here?

Joe McKendrick: Phil, I love that way of putting it, the cloud is SOA done right.  That's a really nice way to put and I agree.  David had mentioned the service level agreements.  One of the big issues that many companies had to come to terms with in SOA is the establishing service level agreements because they necessarily didn't know where the service was originating.  I mean we're mainly talking here about another part of the enterprise, crossing the firewall.  But even crossing -- coming out of a silo and crossing a firewall within an enterprise and using that service and making sure that service -- you could trust that service, you could trust that it has reliability, that its scaleable, it has a lot of uptime, 99999 and so forth.

That was a big issue that need to be worked out just within an organization.  And now, we're asking -- we're preaching to enterprises that they can go outside the organization and use these services from third-party providers for some fairly mission-critical things.  I think it's great that with SOA we worked out a lot of these issues internally.

Ed Horst:  So Phil, --

Phil Wainewright:  Yes, Ed.

Ed Horst:    -- it was embedded your sentence a couple of seconds ago was an interesting modification to what we talked about and I just wanted to double click on a second, which is you used the phrase "you don't know who you're interacting with".  And that's not always true in the cloud side of things.  I mean -- or we should decide whether that's an intrinsic part of the definition of cloud, meaning it's kind of a public interface or is it still a private interface just delivered kind of externally.  

In a lot of the customer examples that we have telco, healthcare, those kinds of things, they're still interacting with a well-known group of users; it's not random don't know who you're interacting with kind of situation.

Phil Wainewright: Well, I mean, I think maybe it would be helpful to bring in the other thing that Joe mentioned in his presentation earlier was this whole encompassing Web Oriented Architecture.  And one of the characteristics of Web Oriented Architecture is the REST interface, the simpler interface that doesn't have all the other stuff that kind of SOAP has involved with it.  And is that a characteristic -- a necessary characteristic of a cloud environment as well that it tends to have these more, I don't know, lowest common denominator interfaces?

Ed Horst:  Our experience seems to indicate that it kind of (Inaudible) about REST, it depends on the nature of the data that's being interacted with.  If it's more transactional in nature, if it's more guarded in nature, its more business critical, oftentimes, the information is coming across SOAP interfaces.  But if it's more kind of query and update and kind of lightweight with less business impact, customers are using REST interfaces.  

And we even have customers that use both for different elements of their application, SOAP for transactional elements and REST for the query and update kind of thing.  Insurance company I can think of that does that today.  So I don't know that -- that's not exclusively, that's not to say that REST can't be used for transactional behavior but when you start to add all the things in there you need in order to do transactions, security elements, and well formed messages and things like that, REST starts to look a lot like SOAP, quite frankly.  

Phil Wainewright:  Well, but does that mean if we start to use the cloud to do more transactional stuff, the cloud is going to look a lot more like SOA, David.

David Bressler:   Well, I think the cloud -- in many ways the cloud really is SOA.  As Ed said, I mean it's going to have API and an API is just -- I mean to me, SOA you'll just be coupling the implementation from the interface so here's a cloud provider, give me an API, boom.  And then you get into the downhill argue of oh, is it SOA or it just a bunch of Web services or just a bunch a services, forget the Web part of that.  But SOA and I know it and I agree on this, we've been doing this with our customers for however many years, seven, eight years now.  

But SOA is often about knowing what's happening within the infrastructure so that you can control, you can decouple, you can control, you can provide agility through insight and knowledge and things like that.  And so, without that infrastructure in place, you don't necessarily have an SOA.  But by the same time, a cloud -- like you said earlier, a cloud forces that infrastructure even if it's not truly there, right.  This is something that's kind of interesting every time we talk about it comes up in my head.  

But you and I are working in the same company.  You have a service, I'm using that, we shake hands, Phil, throw an extra server in there because I'm going to add some capacity.  How much capacity?  I don't know yet.  Okay, we're buds, let's go play golf.  But now, I'm paying you to do the same thing as a cloud provider and I'm going to look at the bill, this natural.  Ooh, how come there's two servers on the bill?  But you might go to your team say, find another service somewhere and put it in.  Yeah, I know we don't have a budget for it, but we'll figure it out.  Let's take this servicer and we'll share it with them and we'll just do it.  

So when its inside the enterprise, you can cut corners.  When its outside the enterprise, you can't and it forces the issue of having this insight whether you have a product like AmberPoint or Actional in there, or whether you don't and you're just coming up with broad brush strokes and saying sure, we'll give you this service level agreement and we'll figure out how to do it later.

Phil Wainewright:  Right.  Okay, so that commercial angle the fact that there are commercial relationships makes you think harder about some of those issues.

Ed Horst:  Yeah, I think that's what David was saying there, yeah.

Phil Wainewright:  Yeah.  So --

Ed Horst:  And you need to dynamically provision these things frequently.  I mean the capacity -- you usually are interacting with a set of expectations that have been set, the agreement side of things and so getting the resources behind that is kind of your responsibility.  

Phil Wainewright: Okay.  So, I think there's a lot of commonality that we've established between SOA and cloud.  Cloud is doing a lot of the things that SOA was setup to enable so; therefore, I think we can go onto perhaps to make the premise that cloud can learn from the experience of SOA.  So what are some of the things that SOA teaches us?  What are some of the lessons learned that we perhaps don't want to repeat the same mistakes when we're implementing cloud?  Joe, do you want to pickup with that?

Joe McKendrick:   Well, okay.  I'm glad David mentioned just a bunch of Web services as an architecture.  Yeah, I've talked about that in some of my blog posts in the past and I see it as evolution.  There's nothing inherently wrong with having a JBos architecture, its apart of the evolution upward the stack toward eventually achieving a fully functioning SOA.  And I don't think most companies are there yet in terms of achieving SOA.  Most companies are in the JBos stage and that's okay.  There's nothing wrong with that.  And we're going to see that with the cloud as well.  

As we move forward with cloud, it is going to be just a bunch of services, a bunch of point-to-point implementations.  The customer -- the sales or the marketing department needs some CRM functionality so they're going to be using some services from SalesForce.com.  IT department is going to need the additional server capacity so it's going to tap into Amazon Web Services for its service.  It's going to be a lot of point-to-point implementations and that's going to be part of the evolution.  And part of the lesson we've learned from SOA going forward is that eventually these things will need to be orchestrated, these things will need governance, these things will need to be tied together in more of a network effect.  

And we're going to being those clouds.  It's interesting a lot of the same issues that we've been addressing and dealing with, with SOA  are transferring to the cloud.  

Phil Wainewright: So what's the lesson learned about avoiding -- I mean to some extent you say, we already are in this situation where we're starting to get these cloud services that have been brought in an ad hoc way.  But David, what are the lessons to be learned about avoiding that becoming a completely chaotic situation?

David Bressler: Well, I think, to me one of the easiest things to do is to put a mediation layer between consumer and provider of services.  It's not the only way to do things and there's all sorts of different architecture discussions we can have, but I think by doing not what you actually do is if you have a boundary where you can actually enforce the loose coupling between the two sights.  To me, the difference between JBos and SOA is the fact that if you have a bunch of Web services, a change in any one of them still breaks the application and that's what we're trying to avoid because you want to be able to version things at different schedules.  

And so if you have two services used in an application, all of a sudden you have all these interdependencies that make it very difficult to move.  This is why SOA came about and this is one of the major things we're trying to accomplish with that.  So this  mediation layer  enables you to do that and I think that's one of the lessons learned.  But I also find it interesting that -- what popped into my head as I was listening to Joe talk is it's almost like there's this analogy between a government that artificially props up an industry.  When -- it if you do it temporarily, then the industry can get on its feet and start running and then the  government support goes away and the industry use kind of has momentum but you'll see things change once the government support happens, usually in the area of pricing.  

Prices will go up and they'll  reflect the true cost of what's going on and I think that's going to happen here as well.  Within the enterprise, because we can cut corners, we didn't reflect the true cost.  The governance issues were done on the backs of probably some really smart IT people, the costs were  pushed out because it's very difficult allocate cost to a project for an enterprise.  As so, but as you put that into a product as part of the cloud, what you now end up with is this true cost will kind of have to come.

The cloud providers will provide a service and then as more robust SLAs are needed, and as other features are needed, the cost of those services is going to have to reflect the true cost.  And I think that is something that will really help because now you actually will have the wherewithal to do the things that you need to do to make SOA or cloud successful.

Phil Wainewright:  Right.  But I think there's an important warning note to be sounded there then David, isn't' there, which is -- and two warning notes actually because what you've just brought up is that probably the providers -- the cloud providers out there at the moment aren't budgeting for all of the things they're going to have to do.  I mean I'm about Amazon Web Services, for example, which to me does not provide enough information to people consuming its compute utility services for them to really to be able to monitor what's going on.

    Likewise, you can't specify which particular country your service are based in if you're consuming Anderson Web Services.  So I mean there are examples where there's going to be a costly infrastructure if you require that level of control, or specification, or contract, whatever you call it on the cloud service that you're consuming.  The other thing going back to the earlier point, which I think, is an important warning is that if you're integrating your cloud services, you talked about mediation David.  If you integrate in a tightly coupled way, then you're actually going to get into these point-to-point integrations that we talked about earlier.  

And therefore, if you want to integrate your Salesforce.com or collaboration software whatever it is, into enterprise infrastructure,  then you should be doing it using mediation technology rather than just a straight point-to-point.

David Bressler: I think it's one of the easiest, cheapest things that companies can do and the challenge becomes what they end up trying to do though is boil the ocean and make their mediation layer some huge enterprise messaging backbone.  

Phil Wainewright: So right, right, yeah.  Yeah, I mean, I think that's -- I'm mean I'm suspicious Ed.  I mean would you bear me out here when I can of going up a wrong track here.  I have a suspicion of big SOA projects that used to happen in the past where people really sort of built an infrastructure and it was lot technologist going around thinking, gee, isn't this great, we can build the best IT infrastructure since the beginning of time and they never stopped to think about actually what was the business requirements and how they could justify all of that investment to the business side.

Ed Horst:  Yeah, in fact, when the topic came up, well what can you learn?  The three things that I've written down here you touched on one of them.  I think the advice besides the architectural elements like David was talking about is intermediation things like that.  I think the lessons learned from SOA are kind of classic.  You could almost argue they're classic software development lessons that people are relearning the hard way and not necessarily by (Inaudible).

I think the three things, one is the -- I think good advice is to start with a specific project that has some kind of reasonable boundaries to it that's going to have daily business impact when it's done.  I'm not saying that you start with your most critical order entry system of you entire corporation, that's the candidate for the first cloud implementation.  But I think you do want something that has regular use.  Again, I'd just characterize it as just daily business impact as your first kind of cloud endeavor.  The other thing is and the one that you just brining Phil is spot on which is avoiding the kind of boil the ocean architecture approach where we're going to get everything to be cloud before we really do anything in cloud and we've seen that in SOA.

We've got a number of -- we've had kind of front row seats at a couple of big projects like that.  One I can think of that ultimate resulted in a 72-page book spec, Dover Dam report, for just the policy part of our system of things that they had wanted because they were looking at every possible policy consideration before they even implemented their kind of their first project.  And I think those boil the ocean approaches probably fail more often than they succeed.  

But that does not say that that first project can be done without regard to some ultimate directions.  So an hybrid, one of the more successful strategies I've seen is kind of a hybrid of kind of broad strokes as to where the overall architecture is going, where we really want to end up in two, or three, or four, or five years even but some real practical realities around that initial project.  And then, I'll touch on something David is kind of bringing up which is kind manage the system, govern the system kind of early and often.  You don't usually regret having done that early on but you often times regret not having done it if you don't.

Phil Wainewright: Right.  Yes.  That I think is absolutely key isn't it?  Its having some kind of architecture that sets the context for what you're doing, and then making sure that the initial assumptions were right as you go on, and then taking that more intuitive approach that we talked about in the earlier Webinar as well, which the cloud should allow you to be more intuitive anyway because you're getting much more immediate feedback to the things that you're pushing out there.

Ed Horst:  Right.  

Phil Wainewright: Let's talk about other elements of architecture because we were talking earlier about the commercial environment and the need to monitor against contracts and SLAs.  So how, I mean, how and do we still need all of the governance and orchestration and ROI infrastructure that SOA provides when we're using the cloud?  David.

David Bressler: Well, I'm not sure what you mean by ROI infrastructure.  Certainly, a governance infrastructure is important and you start to run into the challenge of bringing it all together in a single place.  If you're using multiple cloud providers as SalesForce.com and maybe Intuit for accounting and something, how do you get a view of everything that's happening?  And  you have this in the enterprise today, but again, when you're using external service providers there's a different expectation and that expectation is that you can turn to someone and say is it working and how is it working.  

And so, the challenge is also always ask yourself as an enterprise, as an architect, as a developer, ask yourself if somebody comes up to you and says it's not working and your answer is, well, it's up and running, are you guys really communicating properly?  I find that -- I mean is it working?  The server's up.  That's not what I asked.  I asked is it working and often the answer to that is no.  And so how do you solve that when you're using multiple cloud providers?  I think you need that same infrastructure you've had with SOA.  

Phil Wainewright: Yes, and I think monitoring the service levels is -- because in a sense people always talk about IT being disintermediated and out of a job if everyone put sort of their IT in the cloud.  But actually, the IT people still have to make sure that its meeting the requirements of the business isn't even if someone else is running it.  Then the buck stops with IT.  Joe, do you think that this whole issue of governance and monitoring what you're consuming is going to be an important role?

Joe McKendrick: Absolutely.  One of the lessons we learned with SOA of course, is that you need to involve the business.  It can't be simply an IT initiative, it needs to be driven by the business.  I always liken the way we needed to develop SOA along the lines of a typical homeowner's or condo associations.  Phil you probably have those in the UK as well where --

Phil Wainewright:  Yeah.

Joe McKendrick:   -- you have a lot owners.  You may have a neighborhood with 100 different owners and to some degree, a lot of the services such as maintenance and plumbing, and trash hauling are deferred a management group, the condo association which has power over those things.  And I've always felt that SOA -- that's kind of analogy the way SOA needs to be restructured in the enterprise.  Everybody owns a piece of it but we deferred the management to a committee or a governance committee and IT to some degree to perform implementation.  
Now, the -- I think one of the challenges as well, we're seeing with SOA and we're probably likely to see the cloud as a -- we're not necessarily just going to be consumers of services, we're also going to be producers of services.  I think in every enterprise it's going to both a producer and a consumer of various services, Service Oriented Architecture and extending to the cloud.  And that calls for two levels of governance.  It's been called design time and run time governance but you're going to need to govern the way you build services, the way you deploy services, what resources are available, why you need to deploy those service.  

And at the other end, consuming services, also the way -- what services will you be willing to pay for and how will the cost be structured?

Ed Horst: Yeah, that dual nature Joe is exactly right.  We have a number of customers, Mondial in Europe that does travel information consolidation so they're picking information up from essentially service providers and travel organizations, travel companies and providing value added capabilities on top of it and in turn passing it on to their subscribers.  And so they have to look at SLAs on both sides of the equation.  How am I being served and in turn how am I serving others or how am I serving my customers?  And you need to cover both bases without exception.  

Joe McKendrick: Exactly.  And it's not inconceivable that organizations as producers of these services, obviously, they're producing it for internal consumption but it's not inconceivable that they may be  offering these services.  Well, its already happening.  They offer services through partners.  They have partner networks.

Ed Horst: Yeah.

Joe McKendrick: Services that  enable partners to check on inventory for example, or in the case of travel, to check on  itineraries.

Ed Horst:  Exactly.  

Phil Wainewright:   And actually, another angle that I think people often forget is that cloud providers themselves are affecting the enterprises.  They have and ISVs, particularly who developed the cloud or become cloud providers.  They particularly need to have to the same infrastructure.  And one of the complexities with cloud is that might a tiered infrastructure.  So you might be building on Amazon, you might be delivering your software out to customers, you might also be bringing in backend services as part of your application to (Inaudible) out.  And so there's a lot of different service level contracts that you've got to juggle there.  There's a lot of governance involved in being in that kind of environment.

??:    Well based on --

Phil Wainewright:  I'm sorry.

??:    It's all based on --

Phil Wainewright:  Yeah, what I wanted to move onto was really this issue finally of making sure that we're getting the IT infrastructure, the cloud services, the whole governed architecture aligned with the business need.  What are the things we need to look at/for to make sure that we're really not just getting hooked up with a technology, we're not creating (Inaudible) that are coming to back and bite later on, that we are actually doing something which is a service to the business.  

I described this earlier and confused David by describing it a ROI infrastructure.  But I think this issue of  making sure that the business is service by the infrastructure is quite important one isn't it?  

Ed Horst:  Yeah.  I think the first thing is to make sure that the IT guys are talking the same language as the business guys.  I mean to some degree, even the word infrastructure is something they don't care about.  I mean there business side hears about their business application and most importantly in there the transactions that are flowing through it.  So being able to talk to them about the health of their claims or trades or orders or whatever it is in a meaningful fashion and providing feedback and information on that overall health is the first and foremost thing.  

To a large degree, they don't care whether its SOA, or Corba, or goodness knows what on the way you implement it.  They want to know is their overall application, is their overall transactions going to succeed quickly and reliably.  And talking to them in that terminology is probably one of the paramount goals.  In fact, in large degree, you not even bringing up the SOA or cloud word may even make sense.  I mean why bring those things up with the business side of house if they don't care how you implemented something.

There might be an exception by the way on cloud in one sense, that a lot of the cloud examples reference things like Amazon and Google.  And a lot of non-technical people think they know what those things are.  They're probably not thinking about them in the way we're talking about them today but they think they know what they are.  And so if you drop those kind of names, you probably have a dialog with a businessperson that you couldn't have had you dropped names out of a pure SOA conversation.

Phil Wainewright:  Yeah, that's probably true and of course, we're learning things from these providers because the way that they're doing things is a more sort of consumer individual focused way of doing things and that's feeding back into the way that IT develops and delivers applications.  But I think the point that you made about really being conscious of what it is that's flowing along the top of the architecture from a business perspective.  Is  it an important -- sheds an important light on how you look at the bits and bytes that are flowing within the technology infrastructure because it may be perfect from an engineering point of view in that you're delivering  everything on time.

But from a business point of view, you may actually not be prioritizing the right data packets from the point of view of the business.  So that context and making sure that context is accounted for in the architecture is very important, isn't it.  

Ed Horst:   Exactly.

Phil Wainewright:  David, what other lessons are there from SOA that pertain to cloud or is the rest of it really just involving new  best practices for new environments?  Not hearing David.  Joe, do you want to --

Joe McKendrick: Well, sure Phil.  I think the chief lesson is, as we saw with SOA, is you're not implementing -- you don't want to implement an SOA project.  And you talked about this a little bit earlier in session.  You don't want to implement this or start this gargantuan SOA just for the sake of having SOA.  We need to have an SOA here, let's buy all this stuff and (Inaudible) here.  We need to identify specific business problem, a specific pain point of the business and address it the best way, through the best means and most cost-effective means possible.  And that could be some kind of internal application.  

May be mainframe application is fine for what you require.  The good old CICS application is running fine.  And you can apply to address this problem but there are other ways to do it as well.  You might want to bring in a service from the cloud or you might want to have your IT department design a service or design a composite  that will access that service.  You need to look at the business pain points, look at the business  process and address those issues one process at a time.  You're not doing cloud computing for the sake of doing cloud computing, just as you weren't doing SOA for the sake of doing SOA.

Phil Wainewright:  David, are you with us  now?

David Bressler:   I don't know can you hear me?

Phil Wainewright:  Yes, I certainly can.  Okay, excellent.  For some reason we couldn't hear (Inaudible).

David Bressler:   Yeah, it's funny because I've been sitting here on a headset and it just took the headset off my head.  It's a big professional one and shook and I so I (Inaudible).

Phil Wainewright:  Well, right, okay.  So all the equipment is functioning now.

David Bressler:   And that's funny because that's sometimes how we fix our SOA and infrastructure problems too.  And then you hope they don't come back so maybe that's a good shake.  But if I have a second to answer that you asked.  I think one of t he really important things that we learned in SOA early on was that it's not just about technology, it is about involving the business, but it's also about the culture of the IT department.  It's about looking at things maybe from a product perspective instead of a project perspective within the IT department so that a service is not a project  that they deliver and hand over but something that IT owns over time and in the versions, and then works with multiple business units to make sure that its generally appropriate.  

And so I think in that regard, IT and cloud, IT can use cloud to turn a commodity into a utility.  And then take their expertise and focus on the business.  There's no, in my opinion and slightly off topic, but there's no reason for an IT  department to run e-mail anymore these days  unless you're like the government or maybe some financial applications where you really need strong governance.  Outsource it, have the people doing that do  something much more valuable to your organization.  And I think that cloud will help drive some of that and that will enable the IT people to work more closely with the business to have this attitude of we can prototype.  We can do rapid prototypes, we can change things much more quickly, we can show you what we mean instead of understanding the business environment and going back for an 18-month project and then delivering something at which point the whole business has changed.

And so all of these different dynamics that  come together as a result of cloud, as a result of collaboration tools, and enterprise 2.0, or whatever that's called.  As a result of virtualization and capacity as needed all of these things I think will come together very nicely to enable IT to really become a part of a collaborative team with the business instead of being a plumbing unit inside the bowels of the organization.

Ed Horst:  Yeah, I know.  I think David you're right on there.  I've heard a customer tell and interesting story.  This is good.  A medical alert guys where they will go to kind of brainstorming sessions with the business side of the house, the IT guys go to the brainstorming sessions with the business side of the house.  And they have an architecture setup that's nimble enough that after the meeting is over they'll go back and mock up a system embodies what they were talking about faster than the business guys who'll go back and type up the minutes of the meeting.  

And so the IT guys really have a place at the head of the table in that conversation rather than being somebody that some fully baked idea is delivered and say okay, implement this for us.  It really changes the dynamics when they're able to interact in that fashion.  And I think cloud based systems are going to make that even more real in terms of being able to quickly show the business side of the house what we're talking about here in terms of what we could do to the system and how we can evolve it.

David Bressler:   And to leverage that it frees up the data, this is what's really important, right.  We bring the data together from different places into a single console so that users can understand the relationship and make better decisions, that's fundamentally what we're all here for.  We've just had to work our way up the stack to get there.

Phil Wainewright:  I think that's a great David.  Joe final comment and we've ended up talking about culture.  We're talking about lessons learned.  Do you think that we can look back at the history of SOA and say, yes, IT didn't change  (Inaudible) enough, the cloud is now forcing them to make those changes.

Joe McKendrick: Boy, that's a great way to put us all out.  Yeah, I always try to imagine what it would be like to sit in on at a conference ten years from now and hear what they're saying about the way we handle things today and where things go to in the evolution.  And I think if you're attending a conference ten years from now and you're hearing (Inaudible) talk about the evolution of SOA and cloud, you will see that cloud did change the way we look at SOA and for a couple of reasons.  One, Ed kind of surfaced this line of thought that the business understands cloud far better than (Inaudible) and SOA.  And if you want to sell SOA to the  business, pitch it as cloud.  Pitch it as a company's private cloud implementation -- as its private Software-as-a-Service implementation the business understands that.

And I also want to recall something that Dave had said earlier as well which is really interesting and I think that merits further exploration is the whole cost structure.  The cloud providers will  provide their services at a specific cost, that's the actual cost plus  whatever the margin may be.  Whereas internal IT has always been kind of subsidized.  If you need a  project, you get internal IT to put it together for you, and delivered for you, and a lot of those costs  either were hidden, kind of got dispersed across the enterprise.  Cloud forces you to look at the actual cost of service delivery and perhaps the alignment more with what the market will  be.

Phil Wainewright:  Well, great.  Thanks Joe.  So we're just about out of time now.  So I'll just wrap by saying -- reminding you that I'm Phil Wainewright, I'm with ebizQ and I'd like to thank your guests for a great discussion today.  I'd like to thank Joe McKendrick you just heard, one of my ebizQ colleagues.  Thanks very much Joe.  

Joe McKendrick: Thanks Phil, I think we can call this a "fully baked" session.  

Phil Wainewright:  Excellent.  Good.  I'd like to say thanks to David Bressler, Actional Product Evangelist at Progress Software.

David Bressler:   You're welcome; it's always a pleasure guys.

Phil Wainewright: And Ed Horst, Vice President of Product Strategy at AmberPoint.

Ed Horst:   Thanks Phil and Joe and David.

Phil Wainewright:  So a huge thanks to you our listeners for joining us today too and I hope you will listen into our next two session coming up in today's Cloud QCamp in a few minutes.  on the hour at 2 PM Eastern we have BPM Meets the Cloud with Dennis Byron and Dennis Wall and then I'll be back to join in our final roundtable discussion at 3 PM Eastern where we'll be talking about the Challenges Opportunities of Running BPM in the Cloud.  So I look forward to meeting you again then and in the meantime, do have a great day.

SPECIAL NOTE: We will be exploring many of the business issues shaping the new era of SOA in ebizQ's upcoming SOA in Action virtual conference, to be held October 28-29.

In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more


Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives