Business Transformation in Action

Download file

The following is a full transcript from ebizQ's recent podcast featuring Software AG's Miko Matsumura and myself.

Joe McKendrick:  Hello everyone; thanks for listening into our podcast. This is Joe McKendrick, contributing analyst to ebizQ on all things SOA and author of ebizQ's SOA in Action blog site.  You may have also seen my stuff on the ZDNet SOA blog site as well.  I'm pleased to be joined in this podcast by Miko Matsumura, Vice President and Deputy Chief Technology Officer for Software AG and someone I would consider a leading voice of reason and clarity within the SOA space.  

And Miko, you and I have known each other for some time now, I guess going on five or six years back in the days when you were with INFRAVIO, which later became part of webMethods and now a part of Software AG.  Back then, those were pretty heady days.  Everyone was looking at what they were doing when web services and integration and begin to recognize that, hey, let's see if we can start bringing all these resources together, put then in the registries and repositories, and orchestrate them into more Service Oriented Architectures.  

Of course, this is something that Miko you were talking about even way back then.  Is it fair to say that the SOA space has matured in recent years?  In other words, are we beyond questioning what SOA is and what it can do and it's more of a roll up our sleeves type of stage?

Miko Matsumura: Yes, thank you Joe, for that helpful introduction.  One of the things that I -- when I think about this kind of maturity question is the Gartner Hype Cycle.  So somebody maybe aware that Gartner publishes a Hype Cycle for application technologies.  And if you actually look today at their Hype Cycle for early 2009 to late 2008, the Hype Cycle shows SOA on what they call the plateau of enlightenment.  

Now that's a very important term because really what it means is it means that SOA has an area in both the positive hype curve which is (Indiscernible) beginning, then it has experienced the negative hype curve, and in fact plunged into what is known at the "trough of disillusionment", right.

And the trough of disillusionment -- yeah, it's very famous, right.  It's this moment where people have seen enough actual downside of implementations.  They question even the premise of, well, should we be doing this, right.  But the concept of the slope of enlightenment is really where the technology actually creates the most business impact, which is it's in this gradual rising up from this very sort of low point in this.  

I would say that the lowest point has been marked and I say the low point is probably at the beginning of the year.  And Anne Thomas Manes, a Burton analyst, a friend of mine, and probably one of the progenitors of this SOA game plan pronounced that SOA was dead, right.  Now, if you actually read between the lines of her post, I think you can understand the finer points.  She said that there's even a stronger need than ever for some of these architectural patterns and that enterprise is really in dire need of these solutions, right.  

So I think the SOA is clearly come through this trough of disillusionment and starting to emerge onto the curve -- the slope of enlightenment that's what they call it.

Joe:    And that's a great point, Miko.  And I think it's important to note too that Anne did not discourage the adoption of service oriented principles, rather she was saying that maybe our expectations of SOA as we've known it are changing.

Miko: Yeah, I mean, I think -- let me characterize it a certain way.  Now, tomorrow here in Silicon Valley, I'll be giving a keynote at Software AG's own Cloud Computing Customer Innovation Day.  Now, I realize cloud computer is orthogonal topic to SOA.  But the thing that I wanted to talk about in this context and what I'll be talking about tomorrow is I'll be talking about what I call "scalability of computing".  

Now, when I talk about scalability computing, the thing that leaps to everyone's mind is they think about like, oh, what about transaction speed.  And particularly as I stand as a spokesperson for Software AG who happens to sell the world's fastest online transactional processing database called "Adabas (Mainframe)" products.  People think about scalability they think about, hmm, yeah, that's what scalability looks like.  Well, what I want to talk about is sort of the scalability of computing from a different perspective, which is perspective of teams, right.  And what I mean by scalability teams is that think about the size of a software project, right.  

So look at the smallest size of a software project.  You could measure it by an individual person, right.  So you can say like, okay, some 14-year-old kid, working on their personal computer that's a pretty small project, right.  And as you start to get bigger, you start to -- certain critical mass that ends up being approximately between four to seven people.  And if you look at a team size of four to seven people, you start seeing things like agile development.  

As you start to get a little bigger, you start to get extreme programming and Strum and these types of styles, right.  And what these are, these are change the world types, right.  To get a team of people, the seven samurai, and they're here and they're going to change the world, right.  So the thing that's kind of interesting is what happens if you scale it up a little more?  What about slightly bigger projects, right?  

So if you get the slightly bigger projects you get what I called "tribal computing".  And tribal computing is where things get really interesting because what happens is that when you get to a certain size and organizational designers have what they call magic number.  And what the magic number in organizational design is roughly 150 or so people.  

And the reason why 150 is a magic number is when you actually look at layers of an organization, you assume that people can only manage sort of seven plus or minus a few other people.  You start to get to the point where there's almost like a three-layer hierarchy and what this does is it causes human groups to cleave into tribes.  So whether they be divisions, or ministries, or business units, functional units, geographic units, platform units, like JAVA guys, Oracle guys, Microsoft guys, SAP guys, etc.  Guys, obviously, being gender inclusive.  

Miko: Programmers involved in these tribes tend to (Indiscernible) scale of resolution sort of become self interested, (Indiscernible) combative, political and otherwise difficult, right.  Now, here's the interesting point.  The interesting point that I would like to make is that the way that this manifests is it manifests in the form of what I would call externalities.  

So what I mean by externalities is that the things that -- the cost of behavior of one group are born by a group, right.  I mean, let's look at for example the software life cycle within a larger organization.  So you have developers so if the organization gets large enough and you have segmentation functionally across the life cycle.  

You start to have developers forming their own group, and then you have like provisioning is another group, and operations is another group, and architecture is another group, (Indiscernible) is another and, QA is another group, and you start to have all these different groups that are laid across the sort of development life cycle.  Its development deploy tests, maintain versions whatever (Indiscernible), retire.  

So I guess what I'm trying to say here is that the problems of tribal computing are absolutely (Indiscernible).  If you actually read the Anne Thomas Manes SOA dead post, she's very, very clear that the problem's still there, right, and that maybe there's some fresh approaches that are warranted.  I think the excitement about cloud computing is pretty simple, which is the excited is that people are thinking well, what if we scale back down, right.  What if we scale down to go up?  What if we took steps backwards to go forward?  

And in some ways, we have with SOA.  And so what that looks like is what if you took a team of four to seven and what if you tried to change the world that way?  And you kind of cut them loose a little bit from the sort of bureaucracy and you just kind of bubble them up and let them kind of do what they need to do, right.  

And that's really, what the cloud environment promotes, right.  It moves you from personal computing to universal computing and it gets you to the kind of excitement that all the people in computing used to have when they're sitting in front of their personal computer so many years ago, except for their personal computer is now virtual and it sits in a cloud and sits inside of C2.  And it seems like its one computer but you're actually -- it's actually a single personal computer it's sort of a cloud of universal computers.

Joe: Exactly.  And then have the agility that how do these smaller dynamic teams of developers provide to an operation, right?  Everyone's working at their pace in their area toward the collective goal.

Miko: Exactly.  Exactly.  And so the excitement is about disaggregation.  I think there's a couple of neat things that has emerged that are pretty logical and I would say economically timely, right.  When I say economically timely, is that that some of these tribes in IT have experienced enough attrition that they've actually been reduced to small team size again.  So just attrition and loss of head count has reduced the bulkiness, and the bureaucracy, and the heavy weightiness of enterprise IT to the point where instead of once again lean and mean, and looking for solutions, right.  

And so the question is how can you unencumber your IT?  And the thing that I wanted to be cognizant of, I think, is still the vital topic of the day is that just because things have gotten leaner and meaner, and you've kind of compressed your teams into kind of these potential four to seven teams, which I think are a beautiful scale for software development.  

I mean four to seven developers has changed the world scale.  I mean that's an awesome size for a team.  Just because you've done that does not mean that business units have disappeared.  It does not mean that divisions and (Indiscernible) have disappeared.  It does not mean that politics have disappeared.  It does not mean that software life cycle have disappeared.  

So I think that there's still a need for a coordination mechanism that helps manage contracts, it helps manage trust, it helps manage this idea of composition, and how this element of compute landscape talk to each other, and how they snap together, and how they create the big picture, and the big puzzle.  

Joe: Yeah, and I think I heard you say this a couple of years back, Miko, that the essence of SOA is thinking locally but acting globally, very much a force in action here.

Miko: Yeah, and it's kind of fascinating actually because the way that that thing has evolved -- I just posted my blog about this, sort of the Zen of SOA.  It's really -- the way that people are starting to trace the lines between the local and the global is in the art of measurement and reporting.  And I know that this sounds dry and it sounds kind of like, oh, measurement and reporting, that sounds bureaucratic, we're already in deep trouble.  

But isn't like that at all.  What it's really about is it's about externalities again, right.  And what I mean by externalities is you can trace something that's happening that's an externality and measure it, you can start to create an economy around it.  Like, an example of this at a metaphorical level is carbon credits, right.  The notion is, oh, you've got this coal plant that belching out lots of carbon exhausts, right.  

Now, if you can measure that -- because what are you measuring when you measure carbon credits?  What you're measuring is you're measuring the cost to everyone, the global cost of a local behavior, right.  So in an enterprise, you might find, for example, that there is a local behavior and the local behavior maybe things like non-reuse, right.  So I mean I know that sounds very, like, 2007, 2008 SOA, and I know the word we use is getting through the meat grinder so it's a dirty word, but let's just talk about like --

Joe:  Shared services.

Miko: Let's just talk about generating new code, right.  So I mean what's the cost of generating new code?  Well, it has a downstream cost that impacts testers, it impacts maintainers of code, it impacts people on the application side, bugs and outages and downtime, all this stuff like that, right.  But the cost of generating new lines of code for development is very low, right, because that's what they like to do and (Inaudible).  

So I think the interesting point that I guess I'm trying to make is that if you can kind of measure these things and measure the cost of the externality, then you can start to regulate it in a way that holistic, right.  And so that's kind of what I mean which is to sort of taking this sort of close observation of reality which is do you understand the cost of behavior and then linking that to a sort of a more systematic approach.  

But what I want to emphasis here is that all of this is gentle and yet insistent, right.  And that transformation is gentle and insistent, it's not necessarily rough and command and control, push it all at one big bang, which I think went out with sort of 2007, 2008 trend.

Joe:  Great points.  Great point.  And that's the whole purpose when you look back at SOA is loosely coupled systems working and running independently of each other, services being accessed from other points inside and outside the enterprise.

Miko:  Yeah, yeah, and I think the last thing that I wanted to kind of emphasize here is that there's a very strong baby bathwater thing here which is what we -- what we do want to throw out is we do want to throw out these kind of heavy weight, bulldozer, forced mechanisms of the big bang.  But I think that the thing that is really key insight it's just this notion that we have to continue to make these connections because in a way the word service orientation is key on the (Indiscernible) of service, right.  

Anne finished her SOA dead post by (Indiscernible) with services in a sense you can pick take that (Indiscernible) and say throwaway architecture and stick to services but there's no way that Anne's saying this.  There's no way she's saying forget architecture because you can't just throw out services and forget architecture, it simply won't work; it has no meaning, right.

Miko:  The thing to zero in on is what do we mean by service?  And what I wanted to push is what we mean by service is that people want to be served, right.  Now, I realize that that's an absorbed statement simplistic but what I mean to drive at is that service is about providing value, right.  And anything that is in the way of that is anti-service, right.  And so and... provides value is ultimately any organization is judged by its ability to serve people other than themselves, right.  

Tribalism is sort of runs counter to the organizational need, the enterprise need because the enterprise's need and its charter, and its revenue, or at least its mandate if it's a government organization, citizen mandate is providing service, right.  And so I think the thing that we don't want to lose sight of is that service orientation have to remain alive and well because it really is the central reason to scale organizations.  Like why do we scale organizations?  What's the purpose of scaling organizations?  Why do we have big, big companies?  Why do we have big banks?  Why do we have big governments?  

We're questioning these very things in this sort of inaugural season, at least the United States.  And I think these questions are very legitimate and I think that these organizations ought to be questioned.  But why do we have these big things?  Do we need them at all?  Should we throw them out entirely?  And I think that what we need to converge to is a thought process (Indiscernible).  I do think that there are some reasons why scale is important.  

And I think that what we need to preserve the baby and not the bathwater, what we need to preserve is service, which is that these large entities gain their very charter, their reason for being by being better able to serve more larger numbers of people and that anything that's in the way of that service.  And this is what I mean when I talk about externalities, friction, politics, and backbiting, and all this kind of like tribal manifestations that appear in IT.  These tribal manifestations are really the thing that are anti-service oriented, right.  

These are things that prevent the quality services from reaching people and that these services end up being non-integrated, right, like things that don't have a single sign-on identity are confusing for taxpayers, or for citizens, or for bank customers.  And things that are not integrated, or things that are not connected, and they don't make any sense.  And so when you start to converge to the concept of service as providing this kind of value to human beings at the end, I think that is ultimately the goal and charter, and ultimately the baby within service orientation as opposed to the bathwater.

Joe: Okay.  Great.  Great point, Miko.  Service, an important word we're working with here.  And service is something that that's not going to go away anytime soon.  I want to thank Miko Matsumura, Vice President, Deputy Chief Technology Officer at Software AG.  Miko, thanks for joining us.  It was great speaking with you.  And Miko will also be part of the upcoming SOA Summit being hosted by Software AG, May 5 - May 6, 2009, Scottsdale, Arizona.  We urge everyone who can come out to join us there.  And this Joe McKendrick; thanks everybody for joining us in this podcast.

The podcast is available as an MP3 download.