Client Insights on APIs and Services
KerrieH 110000JQ5R 195 Visitas
5 Things To Know About the Power of the API Economy
The Power of the API Economy: Stimulate Innovation, Increase Productivity, Develop New Channels and Reach New Markets
Stepping Forward into the API Economy
Slideware - IBM Redguide: Power of the API Economy
KerrieH 110000JQ5R 177 Visitas
The API Economy is not just a catch phrase, it is key to accelerating value, improving business performance and extending an organization's business services to the widest audience possible. Making sure your company is easy to do business with and creating paths to new business opportunities is why the API Economy signals a new business reality.
Take a read of a new IBM Redguide on the APi Economy, see http://www.redbooks.ibm.com/abstracts/redp5096.html?Open
There is a 4th era of IT computing comprising several trends:
A new set of drivers and trends, digital transformation drivers, is changing how individuals, organizations and industries engage and work. APIs are the building blocks and glue for digital transformation.
SOA for many has become main stream, a best practice, the optimum approach for the architecture of applications. The arrival of cloud as a delivery mechanism for workloads, applications and innovation; the billions and billions of devices all Internet enabled (rise of Internet of Things); adoption of analytics for Big Data and of course social computing as a catalyst has made for a most interesting change in enterprises.
Many forces (e.g., workloads moving to the cloud, growth of next generation platforms, cloud data management systems, and more, rise of the API economy and others) are at play in the enterprise which as one of my colleagues describes, see Jerry Cuomo's Blog, makes for the engaging enterprise. The enterprise is transforming and we can thank venture capital firms who are investing heavily in services and software start-ups that disrupt the enterprise, read PricewaterhouseCoopers Report. This evolving, engaging enterprise leverages the cloud for product delivery and internal IT, their developers embrace open source, new developers are born who are API driven, and these aren't your mother APIs, these new APIs are services with a bit of a twist, more on that in a future blog post. Prosumers are born, as they both produce and consume technology, they are the new developers. These new developers assemble and APIs are their favorite lego building block.
The enterprise is changing:
Internet born companies have a head start. This post I decided to imbed just in case it ever gets removed but its tells a story of Amazon and SOA that's worth reading. Just think how the brick and mortar enterprise would be today, more agile I maintain, if they had done what Amazon has done. See Steve Yegge's post below.
This blog has shifted from a sole discussion about Client Insights on SOA to Client Insights on APIs and services which includes a dialog about the evolving enterprise, systems of engagements versus system of records, confluence of mobility, social, analytics, cloud and AI all in the context of services and APIs. Stay tuned.
Steve Yegge originally shared this post:
Stevey's Google Platforms Rant, see https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't really have SREs and they make engineers pretty much do everything, which leaves almost no time for coding - though again this varies by group, so it's luck of the draw. They don't give a single shit about charity or helping the needy or community contributions or anything like that. Never comes up there, except maybe to laugh about it. Their facilities are dirt-smeared cube farms without a dime spent on decor or common meeting areas. Their pay and benefits suck, although much less so lately due to local competition from Google and Facebook. But they don't have any of our perks or extras -- they just try to match the offer-letter numbers, and that's the end of it. Their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.
To be fair, they do have a nice versioned-library system that we really ought to emulate, and a nice publish-subscribe system that we also have no equivalent for. But for the most part they just have a bunch of crappy tools that read and write state machine information into relational databases. We wouldn't take most of it even if it were free.
I think the pubsub system and their library-shelf system were two out of the grand total of three things Amazon does better than google.
I guess you could make an argument that their bias for launching early and iterating like mad is also something they do well, but you can argue it either way. They prioritize launching early over everything else, including retention and engineering discipline and a bunch of other stuff that turns out to matter in the long run. So even though it's given them some competitive advantages in the marketplace, it's created enough other problems to make it something less than a slam-dunk.
But there's one thing they do really really well that pretty much makes up for ALL of their political, philosophical and technical screw-ups.
Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon's retail site. He hired Larry Tesler, Apple's Chief Scientist and probably the very most famous and respected human-computer interaction expert in the entire world, and then ignored every goddamn thing Larry said for three years until Larry finally -- wisely -- left the company. Larry would do these big usability studies and demonstrate beyond any shred of doubt that nobody can understand that frigging website, but Bezos just couldn't let go of those pixels, all those millions of semantics-packed pixels on the landing page. They were like millions of his own precious children. So they're all still there, and Larry is not.
Micro-managing isn't that third thing that Amazon does better than us, by the way. I mean, yeah, they micro-manage really well, but I wouldn't list it as a strength or anything. I'm just trying to set the context here, to help you understand what happened. We're talking about a guy who in all seriousness has said on many public occasions that people should be paying him to work at Amazon. He hands out little yellow stickies with his name on them, reminding people "who runs the company" when they disagree with him. The guy is a regular... well, Steve Jobs, I guess. Except without the fashion or design sense. Bezos is super smart; don't get me wrong. He just makes ordinary control freaks look like stoned hippies.
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn't do this will be fired.
7) Thank you; have a nice day!
Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
#6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Armgy Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it.
Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation. There was lots of existing documentation and lore about SOAs, but at Amazon's vast scale it was about as useful as telling Indiana Jones to look both ways before crossing the street. Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included:
- pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.
- every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.
- monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.
- if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.
- debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.
That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers.
This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.
At this point they don't even do it out of fear of being fired. I mean, they're still afraid of that; it's pretty much part of daily life there, working for the Dread Pirate Bezos and all. But they do services because they've come to understand that it's the Right Thing. There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms.
That's what Bezos was up to with his edict, of course. He didn't (and doesn't) care even a tiny bit about the well-being of the teams, nor about what technologies they use, nor in fact any detail whatsoever about how they go about their business unless they happen to be screwing up. But Bezos realized long before the vast majority of Amazonians that Amazon needs to be a platform.
You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?
Well, the first big thing Bezos realized is that the infrastructure they'd built for selling and shipping books and sundry could be transformed an excellent repurposable computing platform. So now they have the Amazon Elastic Compute Cloud, and the Amazon Elastic MapReduce, and the Amazon Relational Database Service, and a whole passel' o' other services browsable at aws.amazon.com. These services host the backends for some pretty successful companies, reddit being my personal favorite of the bunch.
The other big realization he had was that he can't always build the right thing. I think Larry Tesler might have struck some kind of chord in Bezos when he said his mom couldn't use the goddamn website. It's not even super clear whose mom he was talking about, and doesn't really matter, because nobody's mom can use the goddamn website. In fact I myself find the website disturbingly daunting, and I worked there for over half a decade. I've just learned to kinda defocus my eyes and concentrate on the million or so pixels near the center of the page above the fold.
I'm not really sure how Bezos came to this realization -- the insight that he can't build one product and have it be right for everyone. But it doesn't matter, because he gets it. There's actually a formal name for this phenomenon. It's called Accessibility, and it's the most important thing in the computing world.
The. Most. Important. Thing.
If you're sorta thinking, "huh? You mean like, blind and deaf people Accessibility?" then you're not alone, because I've come to understand that there are lots and LOTS of people just like you: people for whom this idea does not have the right Accessibility, so it hasn't been able to get through to you yet. It's not your fault for not understanding, any more than it would be your fault for being blind or deaf or motion-restricted or living with any other disability. When software -- or idea-ware for that matter -- fails to be accessible to anyone for any reason, it is the fault of the software or of the messaging of the idea. It is an Accessibility failure.
Like anything else big and important in life, Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there's more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.
But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.
So yeah. In case you hadn't noticed, I could actually write a book on this topic. A fat one, filled with amusing anecdotes about ants and rubber mallets at companies I've worked at. But I will never get this little rant published, and you'll never get it read, unless I start to wrap up.
That one last thing that Google doesn't do well is Platforms. We don't understand platforms. We don't "get" platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.
But no. No, it's like our tenth or eleventh priority. Or fifteenth, I don't know. It's pretty low. There are a few teams who treat the idea very seriously, but most teams either don't think about it all, ever, or only a small percentage of them think about it in a very small way.
It's a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they're building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I'm concerned, it's none of them. Stubby's great, but it's like parts when you need a car.
A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.
Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don't get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: "So is it the Stalker API?" She got all glum and said "Yeah." I mean, I was joking, but no... the only API call we offer is to get someone's stream. So I guess the joke was on me.
Microsoft has known about the Dogfood rule for at least twenty years. It's been part of their culture for a whole generation now. You don't eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.
Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that's not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there's something there for everyone.
Our Google+ team took a look at the aftermarket and said: "Gosh, it looks like we need some games. Let's go contract someone to, um, write some games for us." Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.
You can't do that. Not really. Not reliably. There have been precious few people in the world, over the entire history of computing, who have been able to do it reliably. Steve Jobs was one of them. We don't have a Steve Jobs here. I'm sorry, but we don't.
Larry Tesler may have convinced Bezos that he was no Steve Jobs, but Bezos realized that he didn't need to be a Steve Jobs in order to provide everyone with the right products: interfaces and workflows that they liked and felt at ease with. He just needed to enable third-party developers to do it, and it would happen automatically.
I apologize to those (many) of you for whom all this stuff I'm saying is incredibly obvious, because yeah. It's incredibly frigging obvious. Except we're not doing it. We don't get Platforms, and we don't get Accessibility. The two are basically the same thing, because platforms solve accessibility. A platform is accessibility.
So yeah, Microsoft gets it. And you know as well as I do how surprising that is, because they don't "get" much of anything, really. But they understand platforms as a purely accidental outgrowth of having started life in the business of providing platforms. So they have thirty-plus years of learning in this space. And if you go to msdn.com, and spend some time browsing, and you've never seen it before, prepare to be amazed. Because it's staggeringly huge. They have thousands, and thousands, and THOUSANDS of API calls. They have a HUGE platform. Too big in fact, because they can't design for squat, but at least they're doing it.
Amazon gets it. Amazon's AWS (aws.amazon.com) is incredible. Just go look at it. Click around. It's embarrassing. We don't have any of that stuff.
Apple gets it, obviously. They've made some fundamentally non-open choices, particularly around their mobile platform. But they understand accessibility and they understand the power of third-party development and they eat their dogfood. And you know what? They make pretty good dogfood. Their APIs are a hell of a lot cleaner than Microsoft's, and have been since time immemorial.
Facebook gets it. That's what really worries me. That's what got me off my lazy butt to write this thing. I hate blogging. I hate... plussing, or whatever it's called when you do a massive rant in Google+ even though it's a terrible venue for it but you do it anyway because in the end you really do want Google to be successful. And I do! I mean, Facebook wants me there, and it'd be pretty easy to just go. But Google is home, so I'm insisting that we have this little family intervention, uncomfortable as it might be.
After you've marveled at the platform offerings of Microsoft and Amazon, and Facebook I guess (I didn't look because I didn't want to get too depressed), head over to developers.google.com and browse a little. Pretty big difference, eh? It's like what your fifth-grade nephew might mock up if he were doing an assignment to demonstrate what a big powerful platform company might be building if all they had, resource-wise, was one fifth grader.
Please don't get me wrong here -- I know for a fact that the dev-rel team has had to FIGHT to get even this much available externally. They're kicking ass as far as I'm concerned, because they DO get platforms, and they are struggling heroically to try to create one in an environment that is at best platform-apathetic, and at worst often openly hostile to the idea.
I'm just frankly describing what developers.google.com looks like to an outsider. It looks childish. Where's the Maps APIs in there for Christ's sake? Some of the things in there are labs projects. And the APIs for everything I clicked were... they were paltry. They were obviously dog food. Not even good organic stuff. Compared to our internal APIs it's all snouts and horse hooves.
And also don't get me wrong about Google+. They're far from the only offenders. This is a cultural thing. What we have going on internally is basically a war, with the underdog minority Platformers fighting a more or less losing battle against the Mighty Funded Confident Producters.
Any teams that have successfully internalized the notion that they should be externally programmable platforms from the ground up are underdogs -- Maps and Docs come to mind, and I know GMail is making overtures in that direction. But it's hard for them to get funding for it because it's not part of our culture. Maestro's funding is a feeble thing compared to the gargantuan Microsoft Office programming platform: it's a fluffy rabbit versus a T-Rex. The Docs team knows they'll never be competitive with Office until they can match its scripting facilities, but they're not getting any resource love. I mean, I assume they're not, given that Apps Script only works in Spreadsheet right now, and it doesn't even have keyboard shortcuts as part of its API. That team looks pretty unloved to me.
Ironically enough, Wave was a great platform, may they rest in peace. But making something a platform is not going to make you an instant success. A platform needs a killer app. Facebook -- that is, the stock service they offer with walls and friends and such -- is the killer app for the Facebook Platform. And it is a very serious mistake to conclude that the Facebook App could have been anywhere near as successful without the Facebook Platform.
You know how people are always saying Google is arrogant? I'm a Googler, so I get as irritated as you do when people say that. We're not arrogant, by and large. We're, like, 99% Arrogance-Free. I did start this post -- if you'll reach back into distant memory -- by describing Google as "doing everything right". We do mean well, and for the most part when people say we're arrogant it's because we didn't hire them, or they're unhappy with our policies, or something along those lines. They're inferring arrogance because it makes them feel better.
But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we're being fools. You can attribute it to arrogance, or naivete, or whatever -- it doesn't matter in the end, because it's foolishness. There IS no perfect product for everyone.
And so we wind up with a browser that doesn't let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I'm actually going blind. For real. I've been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they're quite brazen about it, and Fuck You if you're blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.
It's not just them. It's everyone. The problem is that we're a Product Company through and through. We built a successful product with broad appeal -- our search, that is -- and that wild success has biased us.
Amazon was a product company too, so it took an out-of-band force to make Bezos understand the need for a platform. That force was their evaporating margins; he was cornered and had to think of a way out. But all he had was a bunch of engineers and all these computers... if only they could be monetized somehow... you can see how he arrived at AWS, in hindsight.
Microsoft started out as a platform, so they've just had lots of practice at it.
Facebook, though: they worry me. I'm no expert, but I'm pretty sure they started off as a Product and they rode that success pretty far. So I'm not sure exactly how they made the transition to a platform. It was a relatively long time ago, since they had to be a platform before (now very old) things like Mafia Wars could come along.
Maybe they just looked at us and asked: "How can we beat Google? What are they missing?"
The problem we face is pretty huge, because it will take a dramatic cultural change in order for us to start catching up. We don't do internal service-oriented platforms, and we just as equally don't do external ones. This means that the "not getting it" is endemic across the company: the PMs don't get it, the engineers don't get it, the product teams don't get it, nobody gets it. Even if individuals do, even if YOU do, it doesn't matter one bit unless we're treating it as an all-hands-on-deck emergency. We can't keep launching products and pretending we'll turn them into magical beautiful extensible platforms later. We've tried that and it's not working.
The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.
I'm not saying it's too late for us, but the longer we wait, the closer we get to being Too Late.
I honestly don't know how to wrap this up. I've said pretty much everything I came here to say today. This post has been six years in the making. I'm sorry if I wasn't gentle enough, or if I misrepresented some product or team or person, or if we're actually doing LOTS of platform stuff and it just so happens that I and everyone I ever talk to has just never heard about it. I'm sorry.
But we've gotta start doing this right.
The April 2011 IDC Opinion, article by Stephen D. Hendrick, has an excellent discussion regarding sustainable architecture and expanding the relevance of SOA in business and IT. He writes:
"The term SOA invokes different responses depending upon whom you talk to. Some members of the analyst community feel that SOA is in need of a “makeover.” C-level business managers sometimes grow nervous because of the “A” word in the term SOA. Developers are generally supportive of what SOA represents, and vendors would like to see a higher level of adoption and leverage of SOA products.
Whats missing from these stereotypes is a perspective on what is really happening in the industry. The reality is that IT is in the midst of a very significant transition from software to services. This transition is occurring because of architectural, technological, and business model changes that are designed to expand and enhance the role of IT within the enterprise. This transition from software to services is the next step in the evolution of SOA and provides confirmation that the principles behind SOA are sound and remain relevant in light of the changes that are occurring in IT. "
The author goes on to say,
"As outlined in this white paper, the opportunities clearly outnumber the challenges that SOA faces. A tactical emphasis on data and application integration is often what brings organizations to SOA but the real value of SOA is realized as organizations standardize their approach to application development and adopt modern application development techniques that share a service and business process focus and never lose sight of the architectural discipline that SOA brings to IT activities."
KerrieH 110000JQ5R Identificações:  '100 "soa" on asked soa" answered and questions "what is 2 Comentários 2.733 Visitas
Although I know this could be seen as a shameless promotion of my recent book with my co-author Ali Arsanjani, 100 Questions Asked and Answered on SOA, I thought it would be informative to pick one question from each of the chapters and provide a partial answer that is included in the book. The table of content and acquisition of the book can be found through sites like Amazon: http://www.amazon.com/100-SOA-Questions-Asked-Answered/dp/0137080204.
Zapthink and representatives from some major organizations like Amazon have liked what they have read. The book is organized into the following chapters:
In keeping with the theme of this blog which is client insights, a review of a key question from each chapter fits as I continue to address these questions with practitioners across the world. Chapter 1 SOA Basics has several questions and one question is "What is SOA?"
Although the following is not the complete answer provided in the book it provides a sufficient point of view of how I define SOA. I highlighted the first part of the answer because it summarizes sets the stage for our point of view, on what is SOA.
An agreed-upon definition for SOA eludes the industry. Anyone reading Wikipedia’s definition page for SOA will see the challenges of trying to gain consensus on an SOA definition. Standards bodies, the OASIS group, and the Open Group have provided complementary but different SOA definitions. Presented with a blank sheet of paper, an artist sees a canvas. A poet might fill it with verse. An engineer seizes the opportunity to make a paper plane. Kids may see it as a future pile of spit wads. SOA is that blank sheet of paper.
To the chief information officer (CIO), SOA is a journey that promises to reduce the lifetime cost of the application portfolio, max- imize return on investment (ROI) in both application and technology resources, and reduce lead times in delivering solutions to the business.
To the business executive, SOA is a set of services that can be exposed to their customers, partners, and other parts of the organiza- tion. Business capabilities, function, and business logic can be com- bined and recombined to serve the needs of the business now and tomorrow. Applications serve the business because they are com- posed of services that can be quickly modified or redeployed in new business contexts, allowing the business to quickly respond to chang- ing customer needs, business opportunities, and market conditions.
To the business analyst, SOA is a way of unlocking value, because business processes are no longer locked in application silos. Applica- tions no longer operate as inhibitors to changing business needs.
To the chief architect or enterprise architect, SOA is a means to create dynamic, highly configurable and collaborative applications built for change. SOA reduces IT complexity and rigidity. SOA becomes the solution to stop the gradual entropy that makes applica- tions brittle and difficult to change. SOA reduces lead times and costs because reduced complexity makes modifying and testing applica- tions easier when they are structured using services.
To the IT architect, SOA is the architectural solution for integrat- ing diverse systems by providing an architectural style that promotes loose coupling and reuse. Many IT architects think they have seen this style before with earlier architectural initiatives such as DCE, the Distributed Computing Environment, and CORBA, the Common Object Request Broker Architecture.
To the developer, SOA is a programming model or paradigm where web services and contracts becomes a dominant design for interoperability. It is a web service when it uses a Web Service Description Language (WSDL) or equivalent specification for describing the service. Web services enable organizations to communicate information, using messages, without intimate knowledge of each other’s IT systems.
I met with a team of folks, enterprise architects, application managers, operations managers and executives responsible for various facets of IT in the organization. Everyone had a fairly sound perspective on SOA but the most pressing question was how to make SOA adoption something more than an IT endeavor with a focus on the question of what roles should business play in an SOA journey?
In the ideal world or situation business leaders understand
that differentiation and innovation is made possible by doing something
different. Every organization has access to the same technology, software
products and vendors. Like a car race, all competitors will more or less
have the same racing car design, same number of mechanics, same pit crew.
That being the case strategy means a lot. If you are behind someone,
you're going to be behind them until the finish line unless you do or try
something different. For some organizations it is this genesis that makes
business pay attention because the problem being addressed requires a change.
But this is the easy scenario, the one where business and IT
collaboration is necessary for time to value, for a market opportunity to be
However, even in this scenario there can be false starts. Where SOA is
treated solely as an IT endeavor and the focus is largely on the IT aspects of
service development with no consideration for the role of business stakeholders
to provide value beyond superior integration. Make no mistake improving
integration is good but there may be more opportunity for increased business
In all cases the more business participation presents the greater the success
of deployments because SOA is treated as a journey rather than an end
goal. Funding and governance take center stage versus an after thought.
When SOA is pursued solely as an IT improvement, strong possibilities
exist for derailment, loss of funding / support and for the proliferation of
services which don't make a huge impact on the business in terms of time to
Four business roles exist in the SOA journey which when enacted facilitate a successful SOA journey:
I was discussing the notion most recently with some clients who stated that SOA has failed and that many of their SOA deployments were a failure. I probed to better understand the nature of the failure and could not reach any conclusions about the specifics. It’s rare to hear someone say that the remodeling of my house was a failure. In fact most people would say I had a bad contractor, the project was not done correctly, the project was under estimated or the remodel failed to meet my expectations. In fact one would cite any number of specific reasons but not say the remodel was a failure.
When one does a renovation of their house or a room in their house is the goal renovation or remodeling? I do not think that is the goal, the goal for remodeling the kitchen may be to enhance its look and feel, to introduce superior appliances or any number of specific measurable goals. But the homeowner would never describe the goal as remodeling.
In a like manner, SOA should never be the goal. SOA is a means to an end, an approach, a strategy, a way of doing things. So how can SOA be a failure given this context? What were business the goals or aspirations? Were the specific benefits of adopting SOA defined? Were they measurable? Or did the project assume benefits of SOA would magically come about because the project was classified as a SOA project. What makes the project a SOA project? Are all SOAs created equally? Do all SOAs bring about the same value? The answer is clearly no.
In fact it’s not correct or rigorous to describe or discuss SOA failures as architectures cannot fail, their application and means of adoption might fail. It reminds me of the discussions I have had with developers who describes Web services as slow. Really? Isn’t that relative? What makes a technology slow? Compared to what?
My message is we ought to as software engineers apply some rigor to our thinking about SOA. I will discuss more on this subject latter.[Read More]
KerrieH 110000JQ5R Identificações:  of 'business what is dead value soa 1 Comentário 1.989 Visitas
I was speaking with some folks in the US government and the question of whether was asked, all SOAs are the same? Do they all provide the same value? Are all SOAs created equal? I pondered the question because it is insightful and a question worth exploring.
All SOAs are not the same, they are not created equally and they do not provide the same value. That is, what one deployment describes as an SOA implementation may offer different value than another. For example, I may deploy SOA technology (e.g., an Enterprise Service Bus or a registry) to improve integration flexibility. In one such implementation I might cause IT costs to rise because of the inability to share the infrastructure whereas in another deployment the shared infrastructure was addressed as a benefit to be achieved. In this simple example we see that the two ESB implementations provide different business values in the areas of cost.
Achieving business process flexibility is different than providing integration flexibility. Hence, an SOA deployment might address and provide integration flexibility without providing business process flexibility.
Different business goals (e.g., time to market, lower development costs or lower IT Costs or business flexibility) have both different metrics and require different SOA deployments. That is, the people, process and technology changes are different based on which motivation and goal is sought.
All too often we use platitudes to describe business goals with a measurable understanding of what the goal actually means and how is it actually achieved. Flexibility is the poster child for this platitude thinking. But we can define flexibility, we can measure it and we can achieve it. SOA can make a huge difference.[Read More]
Recently in a discussion with a senior executive at a financial services company he commented that SOA did not deliver the expected benefits. In fact, he went further to say SOA was a failure in his organization. Fortunately, I had the opportunity to gain pretty detail insights into the company’s initiatives around SOA as well as an excellent understanding of their past deployments.
Upon review it became pretty clear that the organization had done significant adoption of Web services. In fact hundreds of Web services were in place without concern for usage, performance and coarseness. It was clear that the organization was equating Web services and SOA as one and the same.
One of the clear lessons learned from organizations gaining business value of SOA is their understanding the difference between SOA and Web services; more on the differences in a latter blog.[Read More]
The highly touted benefit of reuse was discussed with several clients today as a benefit of SOA. So I asked the question of who was are target? Who are we trying to get to reuse things and why? Of course the response is we want programmers and developers to reuse code. More on this point in a moment. Another point was quickly raised as to whether reuse has anything to do with service orientation?
Of course a lot depends on how you define and see SOA and service orientation. That is, do you see SOA as purely an architectural style, is SOA the implementation of Web services, is SOA largely and solely for integration or is SOA about flexibility and adaptability to allow for rapid changes in the business whether it be business process changes, business model changes or other? I think the answer lies in all of the above; however, if we focus our attention on only one item we lose perspective. That is, we minimize the value and benefits of service orientation or SOA.
SOA has a business dimension namely promoting business agility, it has an architecture dimension which is both pertinent to business architecture and IT architectures, it has an implementation view, and an operating view. Limiting our view to just one, limits our understanding of service orientation and of SOA. Resulting in less business value and loss opportunity.
But lets get back to the question at hand which is about reuse. SOA is not about getting developers or programmers to reuse code, whether it be a subroutine, an object, a component or a service. SOA is about getting the organization or line of business to reuse things. Its about getting the business to share and to reuse business functionality across business boundaries, betweeen lines of business, within lines of business and across the enterprise where it makes sense.
If we look at why we are trying to achieve reuse its not because of reuse its because we want faster time to market, lower risk in implementation, seamless view of information or lower costs or improved quality where using the same functionality in multiple scenarios, multiple consumers, multiple channels, multiple applications helps. For example, we can actually effectuate faster time to market if organizations start reusing things a lot more than if developers start reusing things. The vast amount of elapsed time which affects time to market is consumed in figuring out what to do, integration and testing, areas where the developer role has minimal participation in reducing calendar time.
So the point is SOA and service orientation can help organizations and business reuse more things in their business but it requires that we use the construct of a service, not just a facade, not just Web services, but a service which represents a key activity or step of a business process. A service which is used as the structuring element of an application. A service which has the same care and feeding as applications. A service which has its own testing life cycle as an application, a service which has its own published software architecture, a service which is an asset the the business and is treated as such.
Understanding lessons learned from SOA initiatives and projects provides insights on how to get started, creating business value and avoiding pitfalls. For example, some obvious lessons I discussed with a federal government client today included: (1) leading from an IT perspective; (2)treating SOA as same old architecture; (3) big bang approach; (4) equating SOA and Web Services; (5) ignoring or treating SOA governance as an after thought; (6) failure to integrate SOA and Enterprise Architecture thinking and (7) treating SOA as the what and not the how.
Clearly IT leaders should lead, whether its SOA initiatives or not. However, there ought to be business value proposition associated with SOA adoption, whether its flexibility, integration, cost reduction, integration, reducing process cycle time, or others. Of course the key is to take platitudes like flexibility and actually define what is meant. This is a longer discussion but the point is be clear and specific about your business intent and don't let SOA become just another science project.
Treating SOA as what we have done in the past or saying we did this 15 years ago missed the point. Its burying our heads in the sand. Its important to separate the hype but its also important to understand what is actually different from DCE, CORBA and other past approaches.
Obviously risk is lowered by taking incremental steps versus big bang. Organizations must adopt in line with their current maturity.
Many companies have seen the folly of thinking they will get SOA benefits by just using Web services standards and associated technologies. In fact for many companies they are seeing performance issues with their architectural decision to use Web services choices and in others little to no reuse. The point is the choice of Web services is an architecture decision.
Increasingly organizations are seeing that SOA governance must be planned and implemented in order to both achieve project benefits from SOA but especially to see sustained SOA benefits.
SOA can be used to jump start failing or ineffective Enterprise Architecture programs as SOA can be one way to increase the convergence between business and IT. However, SOA and EA are complimentary and SOA should be included in EA not the other way.
Lastly, the goal should not be to implement SOA but rather companies, organizations ought to have a vision where SOA is the how, as where there is no vision, people perish and in this case where there is no vision of how SOA will bring actual value, initiatives stall and fail and SOA gets blamed.
KerrieH 110000JQ5R Identificações:  business bpi of process p2p soa integration eai value 1.918 Visitas
I was meeting with the Deputy CEO of a major Russia bank and we were discussing the modernization of his IT department. Yes, this is a conversation with a CEO who runs a big part of the bank's business plus has responsibility for IT. We were briefly discussing the benefits of point to point (P2P), versus enterprise application integration (EAI) versus business process integration (BPI) using services. The issue centered on the maturity of his organization both business and IT to jump from P2P to BPI. As we discussed the issue he provided an example of a competitor who invested $400M in IT modernization where they did all the right things. The net result was less than a 2% increase in market share. he correctly cited this endeavor as a business failure because they have not recouped the $400M investment and at the end of the day its about making business more effective using IT. Now do not get me wrong he was in favor of moving to BPI but the real question he asked is will he get the same value or some incremental more value than with EAI? Should he start with EAI as he has lots of hurdles just to get this in place. We recommended EAI and I think thats the right choice. But the point is that business value must be paramount in our thinking. There should be no business versus IT just business. when we discuss issues its about business where we will have technical concerns and where some people in the room have IT hats but the conversation is on how we improve the business, make it work, fix whats broken, etc.[Read More]
While in Moscow working with a client the topic of Model Driven Architecture (MDA) and SOA was discussed. The client's view is that MDA in many regards is more advanced than SOA. It is of course an interesting perspective but one I disagree. SOA is not in conflict nor does it compete with any software engineering best practices. Suggesting that one is more advanced than the other places a value judgment on the use of best practices which I don't think promotes their usage.
MDA supports model-driven engineering of software systems. and provides guidelines for structuring various specifications as models. MDA also promotes the use of a platform-independent model (PIM) using an appropriate domain-specific language which can be translated to one or more platform-specific models (PSMs).
SOA's contribution to software engineering is under hot debate and discussion but I assert one of its impacts is in the area of both how we capture business requirements and how those requirements are communicated from business to IT. The notion of a service requires that business no longer push functionality to IT which is housed in silo applications, the function oriented approach. Instead services become first class constructs where they represent an application has more granular reusable assets called services. This changes the software engineering approach in several ways. One notable way is in how many organizations do use cases which have a large amount of behavior of things that occur on the glass, the user interface.
The change in development approach is that the service would be identified prior to use case development and as part of either understanding the business process, its re-engineering or its optimization. Separate use cases would be developed to represent the business functionality needs of the service versus the user interface work flow and design. This will allow for improved separation of concerns down stream during design and development.
But the big point is that this is complimentary to MDA as SOA builds or adds to best practices it does not conflict.
KerrieH 110000JQ5R Identificações:  points get how to soa motivations entry started 1.535 Visitas
OKAY, I have been far too lazy in reporting back various experiences with clients as I discuss SOA. Very recently on a cold day and snowy in Michigan I met with a client who was singularly focused on what to do next. As I would mention motivations and rationales, he would politely communicate that we are convinced on the value and benefits of SOA we simply want to know how to get started or stated differently what have successful clients done to get stated.
So armed with that I articulated that there are different entry points and ways to get started but which one you select often depends on what will work in your culture (that is, your maturity in various aspects of software engineering), your appetite for change, funding models and of equal importance your business goals or motivations.
So I explained the six motivations should be understood so that we can determine the business value desired. That is, it is ill advised to pursue SOA as an end goal instead we pursue SOA as a software engineering best practice, as part of an enterprise architecture approach, part of an IT strategy or as part of a transformational effort (more on this in the future).
Six motivations must be understood because each will cause a different set of actions:
1. Flexibility2. Improved business process (e.g., cycle times, optimization, etc.)3. Revenue increase4. Cost reduction5. Risk and compliance6. Integration So if flexibility is to be something other than a platitude versus a durable statement that has a business and IT impact then one must be specific as to how they will know they have achieved flexibility when it occurs. Does flexibility include reuse? When we look at the SOA solution stack which (see http://www.ibm.com/developerworks/library/ar-archtemp/) which describes various layers in any SOA solution, we see potential reuse at several stages: services sharing, infrastructure sharing, etc. If flexibility is a motivation then we are embarking on a journey, an endeavor that will not be complete with one project but something that will require a program. It requires we address IT and SOA governance.
Improving the business process that involves 3rd party suppliers is an often seen motivation. Typically this involves extranets and is focused on using Web services as both an enabling standard and technology.
For some companies we see a desire to take their legacy assets (e.g., telephony functionality or reservation system) and make this functionality (i.e., services) available for 3rd party application providers or other consumers who build composite applications or sell the services as a part of their capability, resulting in a new revenue stream for the service provider.
Cost reduction often cannot be fully achieved without reuse of services. So often we are looking at using shared services as a way of retiring applications thereby reducing the total cost of ownership of the portfolio. In many cases one can achieve this goal without SOA, but at some point SOA may be necessary as the approach for re-structuring parts of the application and IT portfolio.
Risk and compliance can sometimes translate to exposing services to expose aggregated data or the orchestration of services in a workflow to address compliance.
Integration is a primary motivator for many organizations looking to adopt SOA. Integration has its own obvious benefits but in addition, the choice of applying SOA to integration also inevitably requires the organization decide if this will be a technology implementation or a transformational implementation. Organizations choosing the technology implementation may falsely conclude that they will achieve SOA benefits of reuse simply with the implementation of the technology where in reality they have solely remedied an integration issue. Getting the infrastructure to be shared (i.e. reused) across multiple lines of business (i.e. consumers) requires addressing more than tecnology, organization change management issues become apparent as an example.
SOA is not binary, there are different types of implementation, solutions and motivations. If one does not clearly define the motivation then its quite likely the result will not be met and SOA benefits will become another of IT broken promises.
So how do organizations get started? Of course the devil is in the details, but we have seen five entry points:
1. Technology. Examples are where the organization adopts one or more Web services standards or a product in the context of a sandbox to introduce the technology into the organization. Often there is also a project which can take advantage of the technology. This could also be the introduction of information as a service. For example, the aggregation of data from multiple sources might be best achieved using a service.
2. Business process management. In this example, the focus could be on improving or optimizing or developing automation for one or more business processes.
3. Connectivity. Integrating services across multiple applications inside and outside the enterprise for one or more defined business objectives
4. IT transformation. In some cases organizations have a "burning platform" which means that the technology or the application in its current state will not be able to meet foreseen business requirements presently and in the foreseeable future. Or the problem could be that IT requires a major improvement in its application delivery capabilities or it could simply be that IT costs have spiraled to unacceptable levels dictating IT simplification, IT optimization and other changes. Within this entry point multiple business motivations may be at play. Organizations could be trying to do more for less where they then examine how to increase the amount of reuse.
5. Business transformation. This is a case where due to regulatory changes, a public embarrassment, lack of sticky customers, changes of business models or whatever the business motivation, there is a need to do business and It transformation in parallel. Often this focuses attention on specific business scenarios that require addressing whether its people centered or process centered.
In addition we then discussed several case studies and I introduced the notion of a maturity model for providing a route map, a guide.[Read More]
Just recently in some meeting with clients in Budapest several questions were raised about what is truly different about SOA than previous approaches to improve IT agility? The history of COBOL (Common Business Oriented Language) being touted as a means to improve business and IT linkage was raised along with innovations in object-oriented development and component based development.
Rather than discuss the merits or pros and cons of each of these technology innovations I chose instead to focus on what is actually different with SOA. I described five differences:
(1) The ubiquitous presence of standards is actually different. The use of XML and WSDL or derivatives is a major difference. In addition, the way in which vendors author standards has also improved.
(2) A focus on interoperability versus integration is a key difference between SOA and prior approaches. Using the metaphor of applications as islands, integration is about creating bridges between these lands masses; interoperability is more like being teleported as in Second Life.
(3) The linkage between business and IT is different in that SOA makes the assertion that all businesses have a business design which describes how the business operates such as its business processes, the services rendered and consumed, business goals and objectives, business rules and policies. The business design ought to be a tool to communicate requirements between business and IT. Hence the use of business process models and BPM, where both process models and services have a distinct and clear relationship is different than previous approaches. Promoting the best practice of documenting as much as possible of the business design with tooling rather than the more common approach of using word processing or drawing tools is also different.
(4) The focus on reuse is also different in that with SOA we are focused on improving the organizational productivity versus a focus on developers and programmer productivity.
(5) Software design is also different. See Don Ferguson's blog (http://www-03.ibm.com/developerworks/blogs/page/donferguson) which I have included herein: Web services are more language independent than previous approaches. For example, CORBA was very C-like and was awkward in Smalltalk. EJBs and Java are, by definition, focused on the Java type space. XML renders more naturally into multiple languages like C, Java, COBOL, etc. XML and Web services are less fragile and better accommodate change. For example, it is possible to add or reorder elements in an XML business object without necessarily breaking code using older versions. The same applies to WSDL. Most previous approaches like RPC or CORBA were often a distributed version of a runtime model with offsets into data structures or function tables. So, additions and reordering broke code. Previous approaches really had three data models and type spaces. For example, a CORBA application had: 1) IDL, 2) IIOP for inflight messages, 3) SQL if the application was accessing a database. Distributed Java has a similar approach with serialized objects, the Java language and JDBC/SQL. Web services have one type space (XML) for interfaces, data applications are manipulating, XML databases and in-flight messages. It may not be obvious why one type space is better than three. The primary reasons are simplicity and flexibility. In Web services, there could be one basic approach for converting a data structure/business object from one format to another, instead of potentially three different type models and tools. This could enable a simpler development tool suite and API set. Moreover, having a consistent model enables flexible and more dynamic placement of business logic. The transformation code could run in an application, in an active database or in network intermediaries (proxies). We designed Web services to support both asynchronous messaging and remote procedure call. Previous approaches started with one or the other, and then grafted the other model later on. For example, implementing a layer on top of MQ for simple RPC is common. CORBA was originally RPC centric, but then added support for asynchronous messages. In most cases, the after the fact grafting of one technique on another was awkward and error-prone.
So when you add these all five things together you see there is something different. This is not a case of a shell game. In fact the only thing that is the same is the use of SOA as an architectural style, where we have the notions of consumer, provider, service description, broker, and a registry are similar to previous approaches. Of course many technical people see SOA as solely an architectural style and this misses the point entirely of service orientation.[Read More]