Information technology is now entering an unprecedented era of rapidly expanding development productivity. This is because of two unassailable facts: The number and types of people who can actively participate in software development are expanding, while -- at the same time -- we're seeing a rapid compression in the effort, cost and risk of taking applications and services from concept into full production.
Put these trends together and we enter a fertile new era of diverse applications and services creation, one that offers developers more choice on how to build, and offers architects more choice of how to deploy (including broader use of web services and hosting to the "cloud"). The trends auspiciously portend less risk for businesses, both for entrepreneurs and enterprises alike, to innovative in ways that more easily bring applications to markets via the Internet.
The entrepreneurs are groking this all just fine, while the enterprises are quickly recognizing that they face new upside benefits as they adopt so-called Enterprise 2.0 approaches. Such development process improvements as "application lifecycle management 2.0", open source development communities such as Eclipse, and a widening embrace of Agile development practices are quelling enterprise IT leaders' fears of development project misfires.
In the mostly consumer-facing Web 2.0 arena, the ongoing mash-up of the definitions of developer and entrepreneur among start-ups allows for a flowering of innovation with relatively low up-front costs. If an application or service doesn't work in gaining wide use and appeal, these innovators keep on changing it until it does. Google is a prime example of this tinker-to-success mentality.
Other accelerants to the ease-of-development trends are the wide embrace of open source tools, preference for rich Internet applications (RIAs) approaches (highlighted by the recent Microsoft Silverlight unveilings), and openly available APIs for myriad ecommerce and social networking Web services from the likes of Google, Amazon, Yahoo!, Salesforce.com, and Microsoft.
I'm also seeing a variety of new automated development workflows and requirements gathering approaches that bring non-developers increasingly into the act of defining, adjusting and implementing applications. These folks are not coders, but they are keen on business transformation via re-engineered business processes. The more tools that close the gap between process efficiency knowledge and the implementation of such productivity enhancements via IT, the more that talented non-developers will deeply exploit IT for their business goals.
A prime example of such tools and approaches is One Team Technologies, a Chicago-based start-up that walks non-geeks through a series of menus and choices -- selecting new options based on the roles and choices of the creators -- to design database-driven, potentially mission-critical applications. I think venture capitalists ought to use this technology and approach to incubate even more innovative start-ups, and create more business process-focused applications that can be delivered quickly to dynamic enterprises and markets.
And while this trend toward design automation and inclusion of more non-coders into development makes sense for start-ups and Web 2.0 greenfield innovators, the fruits of this broadening portfolio of possibilities will soon benefit SMBs and enterprises as they embrace software as a service (SaaS) and on-demand delivery of applications and integration services. SaaS also accelerates the ability to mash-up and use the services provided from communities of functional interest and from vertical industry niches. That is to say that those hosting organizations interested in proving on-demand applications will increasingly provide the tooling to create and adapt applications all the more appealing to more businesses.
The road from application service innovation to full production, as I mentioned, is already rapidly compressing. A great example of this compression effect comes from Bungee Labs' Bungee Connect offering, which debuted at Web 2.0 Expo. Another way of describing Bungee Connect is software development and deployment as a service (SDDS). Bungee Connect combines the virtues of online web application development with a near-real-time test and debug capability and with a click-to-host service that — now here's the rub — costs the developer next to nothing to get into full production.
Here's an offering that recognizes that new business models that vastly expand the universe of web services players is what the web is all about. The Bungee Connect service began allowing beta use access on May 1. Developers may register to participate in the early-access beta program.
Bungee Connect gives developers WSYWIG, drag-and-drop, rich Ajax interface creation tools online. Those familiar with scripting and web applications development can begin creating web applications from a library of Bungee functions, or create their own services, or mash-up ones from a core of providers: Amazon, Google, Salesforce.com, Yahoo!, Real Networks, Windows Live, PayPal, and eBay.
The cost for the use of the tools, testing, and then hosting is free, and the subscription cost for the at-scale hosting only kicks in based on the use of the application by end users. Low use means low costs, and high use means a predictable measure of the proceeds goes to the development and hosting service. The hosting business stays with Bungee as the grid services provider while the applications ramp up into a sustainable business. Bungee collects rent — so to speak — based on use of the underlying infrastructure. Pay as you grow.
The net effect of these trends and examples is that the time, cost and risk of going from design to full production are deeply compressed. We are entering a period on unmatched applications, services, and media creativity.
Shouldn't you and your company be a part of it?
Sunday, July 15, 2007
Thursday, July 12, 2007
Red Hat delivers middleware stepping stone to larger platform distribution in fall
Red Hat has cemented another large stone into the foundation of its Enterprise Application Platform (EAP) 5.0, expected later this year, with the announcement of middleware solution EAP 4.2.
EAP 4.2, the company's most comprehensive enterprise platform, weaves JBoss, Hibernate, and JBoss Seam into a single (integrated, tested, and certified) platform for Java applications. The new direction is an outgrowth of Red Hat's announcement in April that it had decided to split its efforts into the traditional JBoss.org releases, following the traditional model, and the JBoss.com enterprise releases, for which Red Hat will sell support.
Key components in JBoss Enterprise Application Platform 4.2 include JBoss Application Server 4.2, Hibernate 3.2.4, JBoss Seam 1.2, and JBoss Transactions 4.2.3. It also sports embedded Apache Tomcat 6, a web services stack, support for ful J2EE 1.4 services with extended support for the common Java EE 5 features.
JBoss Enterprise Application Platform 4.2 has been certified on different operating systems, including Red Hat Enterprise Linux 5, HP-UX, Solaris, and Windows; Java Virtual Machines from BEA, HP, and Sun Microsystems; and databases such as Oracle, Microsoft SQL Server, MySQL, and Postgres SQL. It will also be available in seven languages.
Red Hat is moving closer to a full SOA infrastructure offering.
JBoss CTO Sacha Labourey blogged about the new release, saying that Red Hat had bundled in as many of the EE5/EAP 5.0 modules that had already been finalized, anticipating the next release.
The indication there is that there's no time to waste in getting a full open source SOA stack to the market, one that Red Hat hopes sets it apart from the commercial and other open source alternatives.
IT analyst and blogger Tony Baer over at OnStrategies, wrote about the Jboss.org/Jboss.com split, when the announcement came out last April. He sees Red Hat as not buying to the Eclipse model and, rather, creating what he calls "its own parallel universe."
EAP 4.2 is available now from the Red Hat online store or from resellers.
EAP 4.2, the company's most comprehensive enterprise platform, weaves JBoss, Hibernate, and JBoss Seam into a single (integrated, tested, and certified) platform for Java applications. The new direction is an outgrowth of Red Hat's announcement in April that it had decided to split its efforts into the traditional JBoss.org releases, following the traditional model, and the JBoss.com enterprise releases, for which Red Hat will sell support.
Key components in JBoss Enterprise Application Platform 4.2 include JBoss Application Server 4.2, Hibernate 3.2.4, JBoss Seam 1.2, and JBoss Transactions 4.2.3. It also sports embedded Apache Tomcat 6, a web services stack, support for ful J2EE 1.4 services with extended support for the common Java EE 5 features.
JBoss Enterprise Application Platform 4.2 has been certified on different operating systems, including Red Hat Enterprise Linux 5, HP-UX, Solaris, and Windows; Java Virtual Machines from BEA, HP, and Sun Microsystems; and databases such as Oracle, Microsoft SQL Server, MySQL, and Postgres SQL. It will also be available in seven languages.
Red Hat is moving closer to a full SOA infrastructure offering.
JBoss CTO Sacha Labourey blogged about the new release, saying that Red Hat had bundled in as many of the EE5/EAP 5.0 modules that had already been finalized, anticipating the next release.
The indication there is that there's no time to waste in getting a full open source SOA stack to the market, one that Red Hat hopes sets it apart from the commercial and other open source alternatives.
IT analyst and blogger Tony Baer over at OnStrategies, wrote about the Jboss.org/Jboss.com split, when the announcement came out last April. He sees Red Hat as not buying to the Eclipse model and, rather, creating what he calls "its own parallel universe."
EAP 4.2 is available now from the Red Hat online store or from resellers.
Wednesday, July 11, 2007
Parsing search marketing, the 'content pyramid' and RSS strategies with Sam Whitmore
Read a full transcript of the podcast. Listen to the podcast.
In my work covering enterprise application development and deployment strategies, I often find myself also witnessing a sea-change in how software providers market their values. Software has always been a challenge to market, and many of the most innovative thinking in online marketing has come from the software industry.
I'm now seeing four distinct legs of support under the software marketing bench: 1) traditional internal marketing (web sites, downloads, product literature), 2) traditional external marketing (advertising, events, webinars, lists, email, newsletters), 3) viral (blogs, podcasts, videocasts, community sites, social media), and 4) search (all of the above plus tagging, sharing, community, relevance).
I'm also seeing a hastening shift from the second leg to the third and fourth, in terms of investment and expected return. Companies are shifting the emphasis from tradition to social media.
Creating and distributing good content is essential to all these activities, and accelerates the movement to social networking and community development. I recently had a podcast conversation with Sam Whitmore, editor and proprietor of Sam Whitmore's Media Survey, in which we discuss these themes along with the burgeoning role of RSS, community, conversations, and search.
Together we wonder whether the "public" relations community will soon gain a new cohort, the "search" relations person. It's a new way to reach the public, the right public, and on the public's terms. Their search terms. Search is the new media.
Here are some excerpts:
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
In my work covering enterprise application development and deployment strategies, I often find myself also witnessing a sea-change in how software providers market their values. Software has always been a challenge to market, and many of the most innovative thinking in online marketing has come from the software industry.
I'm now seeing four distinct legs of support under the software marketing bench: 1) traditional internal marketing (web sites, downloads, product literature), 2) traditional external marketing (advertising, events, webinars, lists, email, newsletters), 3) viral (blogs, podcasts, videocasts, community sites, social media), and 4) search (all of the above plus tagging, sharing, community, relevance).
I'm also seeing a hastening shift from the second leg to the third and fourth, in terms of investment and expected return. Companies are shifting the emphasis from tradition to social media.
Creating and distributing good content is essential to all these activities, and accelerates the movement to social networking and community development. I recently had a podcast conversation with Sam Whitmore, editor and proprietor of Sam Whitmore's Media Survey, in which we discuss these themes along with the burgeoning role of RSS, community, conversations, and search.
Together we wonder whether the "public" relations community will soon gain a new cohort, the "search" relations person. It's a new way to reach the public, the right public, and on the public's terms. Their search terms. Search is the new media.
Here are some excerpts:
We're now getting people to understand the concept of "You don’t have to browse anymore." They still search, of course, probably more than ever before. But you think about the two ways ... that people get their information now, it's either through RSS syndication, or through search. And it’s almost quaint to think back about, "Yeah, I think I am going to go through my bookmarks and see what I haven’t visited in a while." I don’t know anybody who does that anymore.Read a full transcript of the podcast. Listen to the podcast.
The idea is to start thinking strategically about your content. Instead of having thousands of people around your company, each creating their own content without much interaction about it, without much coordination about it -- but perhaps a lot of overlap and a lack of reuse -- adding to more of a case of redundancy. And that goes for everything from mimeographs to RSS feeds, and all in between.
But when you think about content more strategically -- and can plan for and create core content that they can be reused and extended across different uses, like marketing literature, the documentation you provide for your services and products, your advertising, as well as your communications with your investors, with analysts, with press -- you create more of a coordinated core set of messages and documents and content. And we'll be seeing more audio and video increasingly in this mix.
If a company can create this content core and allow people to use it and make it accessible -- in the same way as with the development of software tools and components -- you can better control your costs; you can control better your message because more of your messaging will be in sync, because its all coming off of the same core.
Any company that has a strategic direction that they are taking their business to should say, “What are the keywords that relate to our future? What is the content we can create that will drive recognition from those keywords of our value, specifically as an individual company? And how can we create an ongoing process by which we’re feeding that algorithm machine over and over again to retain that high ranking?"
That to me is marketing 2.0.
I think that these IT trade titles and these people that are being rapidly disintermediated, they need to figure out how to get some of their content to rank well in generic search environments. And that brings us back to SEO and the fact that you can subscribe to RSS search results and these people really are getting hammered.
The way you go about a whitepaper is you do research, you get information and you do interviews -- primary research. And what is an interview? It’s a discussion. Why not just create a great discussion with the experts and put that up, instead of putting it into some sort of a turgid-prose, 80-page tome that people only read the executive summary of?
Why not give the long tail its due and put up a series of five key discussions with the experts you would have interviewed anyway for the whitepaper, and let people either read the transcript or glance at the executive summary of each individual interview or discussion, and then pick and choose? To me that’s just a better way to learn. And it also, by the way, is a lot easier for the experts as well as the authors. So it really is a discussion.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production. Dana Gardner’s Podcast on Marketing 2.0 with Sam Whitmore. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Tuesday, July 10, 2007
IONA corrals open source SOA assets under FUSE brand, further aligns with Apache
IONA Technologies' acquisition of LogicBlaze last April has culminated in the announcement this week that IONA's providing a coordinated array of open-source products available under the new FUSE family.
Based on projects hosted by the Apache Software Foundation, the FUSE components will provide messaging, SOA connectivity, and service enablement for a variety of IT environments. All are interoperable with Artix, IONA's commercial SOA infrastructure.
When it announced that it had acquired LogicBlaze, IONA leaned heavily on the fact that the deal included SOA heavy hitters Hiram Chirino, Rob Davies and James Strachan, who have impressive resumes and were undoubtedly key to IONA's support strategy with the new FUSE products.
IONA said at the time "LogicBlaze's employees are respected experts in the open source community, and are key contributors to the most popular open-source projects related to SOA, including Apache ActiveMQ and Apache ServiceMix."
Does the latest announcement mean that IONA is dumping Celtix in favor of the FUSE ESB? That's the question that Jason Stamper of Computer Business Review Online put to Larry Alston, IONA's general manager of open source. It’s just the opposite, Alston told Stamper:
IONA FUSE consists of:
A new Website for the FUSE community -- open.iona.com -- features user forums, wikis, tutorials, sample applications, and documentation for spurring on FUSE adoption. The site also features downloads, access to tooling, and early access to additional project code.
Disclosure: IONA is a sponsor of BriefingsDirect B2B podcasts.
Based on projects hosted by the Apache Software Foundation, the FUSE components will provide messaging, SOA connectivity, and service enablement for a variety of IT environments. All are interoperable with Artix, IONA's commercial SOA infrastructure.
When it announced that it had acquired LogicBlaze, IONA leaned heavily on the fact that the deal included SOA heavy hitters Hiram Chirino, Rob Davies and James Strachan, who have impressive resumes and were undoubtedly key to IONA's support strategy with the new FUSE products.
IONA said at the time "LogicBlaze's employees are respected experts in the open source community, and are key contributors to the most popular open-source projects related to SOA, including Apache ActiveMQ and Apache ServiceMix."
Does the latest announcement mean that IONA is dumping Celtix in favor of the FUSE ESB? That's the question that Jason Stamper of Computer Business Review Online put to Larry Alston, IONA's general manager of open source. It’s just the opposite, Alston told Stamper:
"To say that would be plain wrong. Celtix had become CXF in Apache, and CXF is one of the underpinning projects in FUSE, too. If anything, we're fusing Celtix and LogicBlaze."The assemblage of these components rationalizes and streamlines the open source SOA approach that IONA is banking on to grow its traditional and the emerging SOA businesses. The components provide an on-ramp for a variety of types of users, developers, and architects. The variety of offerings allows flexibility on adoption paths, to find the right fit for SOA infrastructure, while leveraging the benefits of an Apache open source license and community.
IONA FUSE consists of:
- FUSE ESB -- Based on the Apache ServiceMix project, FUSE ESB is built on the Java Business Integration (JBI) specification.
- FUSE Message Broker -- Based on the Apache ActiveMQ project, FUSE Message Broker is a JMS-oriented messaging platform.
- FUSE Services Framework -- Based on the Apache CXF project and formally known as the Celtix Advanced Service Engine, the FUSE Services Framework is designed for service creation, integration and reuse of technical and business service components.
- FUSE Mediation Router -- Built upon the Plain Old Java Object (POJO)-based Apache Camel project, FUSE Mediation Router provides a lightweight, rules-based and transport-neutral routing and mediation engine that leverages Enterprise Integration Patterns.
A new Website for the FUSE community -- open.iona.com -- features user forums, wikis, tutorials, sample applications, and documentation for spurring on FUSE adoption. The site also features downloads, access to tooling, and early access to additional project code.
Disclosure: IONA is a sponsor of BriefingsDirect B2B podcasts.
Movie Review: Greg the Architect provides stiff performance in SOA thriller
Unaccustomed as I am to reviewing animated short features, the latest installment of "Greg the Architect" squarely tackles the confusion many enterprises encounter over SOA.
Throughout the clip we are left hanging on an emotional cliff, trying to decide if Greg can focus on SOA rather than be overcome by myriad nonsensical distractions from vendors and industry analysts. [I'll drop the price of that ROI assessment to $9k and guarantee delivery in 14 months.]
Greg the Architect is a creation of TIBCO Software. In the latest installment, "Focus Pocus," Greg, a long-suffering enterprise architect, desperately needs a vacation, but he's sidetracked by Jerry, the CIO, and dragged to a SOA conference at the Biscotti Center.
I don't want to reveal the thrilling conclusion, but let's just say it involves a colleague, a small mountain of turgid white papers, and a clever subterfuge by our hero, Greg.
In Focus Pocus, Greg's performance comes across a little stiff, although that may have a lot to do with the fact that all characters are portrayed by GI Joe-type action figures (Thunderbirds?).
Enterprise architects may see themselves as a little more flexible than that. If the producers want to win over architects, claymation may be the way to go (Gumby?). Let the architect bend a little to adapt to the situation. And your little pony, too.
Greg started out as part of the SOA Now Journal, also produced by TIBCO, and he now has his own Web site (fan club?), where viewers can see past episodes and download "fun stuff." A social SOA network in the making.
Perhaps TIBCO should consider a virtual reality game where users could put Greg through some grueling IT paces, sort of like Toontown Online meets Second Life meets the corridor outside a typical CIO's office. Flying white papers that land anywhere but on your head would cost 20 life points. Data cleansing stations could renew his energy. The registry/repository lounge could be where text messages are shared with end users. The player with the shortest requirements list at the end wins. [No charge for that consulting, BTW.]
Throughout the clip we are left hanging on an emotional cliff, trying to decide if Greg can focus on SOA rather than be overcome by myriad nonsensical distractions from vendors and industry analysts. [I'll drop the price of that ROI assessment to $9k and guarantee delivery in 14 months.]
Greg the Architect is a creation of TIBCO Software. In the latest installment, "Focus Pocus," Greg, a long-suffering enterprise architect, desperately needs a vacation, but he's sidetracked by Jerry, the CIO, and dragged to a SOA conference at the Biscotti Center.
I don't want to reveal the thrilling conclusion, but let's just say it involves a colleague, a small mountain of turgid white papers, and a clever subterfuge by our hero, Greg.
In Focus Pocus, Greg's performance comes across a little stiff, although that may have a lot to do with the fact that all characters are portrayed by GI Joe-type action figures (Thunderbirds?).
Enterprise architects may see themselves as a little more flexible than that. If the producers want to win over architects, claymation may be the way to go (Gumby?). Let the architect bend a little to adapt to the situation. And your little pony, too.
Greg started out as part of the SOA Now Journal, also produced by TIBCO, and he now has his own Web site (fan club?), where viewers can see past episodes and download "fun stuff." A social SOA network in the making.
Perhaps TIBCO should consider a virtual reality game where users could put Greg through some grueling IT paces, sort of like Toontown Online meets Second Life meets the corridor outside a typical CIO's office. Flying white papers that land anywhere but on your head would cost 20 life points. Data cleansing stations could renew his energy. The registry/repository lounge could be where text messages are shared with end users. The player with the shortest requirements list at the end wins. [No charge for that consulting, BTW.]
Monday, July 9, 2007
SOA and SaaS convergence produces new integration-as-a-service benefits
Read a full transcript of the discussion. Listen to the podcast. Sponsor: Cape Clear Software.
As the use of Enterprise 2.0 mashups sweeps the IT industry, the concept of converging enterprise services has expanded to hosted munging of business applications and back-office functions.
Why not extend SOA itself by embracing more integration services that help vendors, ISVs, and service providers bring more elements of business processes together, too?
The budding notion of "integration-as-a-service" allows enterprise business leaders to "shop around" for their services, regardless of hosting, and opens up the prospect for a thriving new ecology of services and integration models for mission critical activities. The advancement to SOA for many companies may well be accelerated by more choices on means of connection, both inside and outside the organization's own IT boundaries.
I recently conducted a sponsored BriefingsDirect podcast discussion with Annrai O'Toole, CEO of Cape Clear Software, on the eye-opening prospects for integration as a service. Early adopters are already outsourcing aspects of integration. The implications are staggering: Business operators and entrepreneurs create and amend complex processes and workflows through a simple point and click interface on someone else's infrastructure. Pay by the use or general subscription. Retain control over data and ID management.
Here are some excerpts:
A couple of factors are driving this. First, it’s the whole technology maturity thing. Six or seven years ago, the standards around Web services were in their infancy, and people didn’t have a lot of experience with them. Because they were young, unproven, untested, and lacking in key bits of functionality, people didn’t really want to go there. Technology is one element of it, but there are a few more important elements driving it as well.
One is a secular trend toward simplicity and flexibility. At some levels, this has been driven by teams through virtualization. Storage and processing power are being very quickly virtualized. Applications are being virtualized, with software-as-a-service on demand. There is a long-term shift by customers, who are saying, “We don’t want to own complex infrastructure anymore. We’ve been there, and done that. We want something else.”
We had an RFP come in – and this isn’t all that unusual – from someone looking to do a big SOA initiative. It was – and I’m not joking -- a 111-page RFP.
Customers look at the choices available to them, and say, “Do we want to do all this big SOA integration on our own by buying these complex things, or are we prepared to look at alternatives? And, do those alternatives have any reality?” They do, and many companies are shying away from these big, complex initiatives.
You can sit in a room with a bunch of executives, both from the business and IT segments and, say, “Hosted integration is a good idea,” and they’ll know that. We’ve got some proof points around it. Most notably, one of our marquee customers in the software-as-a-service base is Workday. The PeopleSoft founders got together to rebuild an ERP application, but this time on a hosted basis.
We’ve seen two fundamental preferences here, and there are two options for what you want to host. The first option we would broadly categorize as very loosely coupled data transformation. A lot of the things that people need to solve in terms of integration problems are really data transformation. How do I take payroll information from one provider, transform it, and send it down to another provider? Most people can deal with that. Most people can wrap their head around how that can be done in a hosted manner. What’s involved there is that it’s loosely coupled and it’s data. It’s ultimately some kind of XML or it gets converted into XML somewhere along the line.
The next thing is a step up from that. Now that I can get information between these things, do I want to have some orchestrations or some kind of inter-company business processes? It’s not just getting data from A to B, but it’s, “I want to get data from A to B, and then I want to call C, and when C has completed its job, then I want to call D, and when that’s complete, the whole thing is done.” That’s next level of complexity, and it involves a more sophisticated approach. But, both of them are possible and both are in operation today. As far as what customers are going to go for, I think they’ll be happy to do data transformation initially, and when that’s really working for them, they might be prepared to take the next step and host business processes in the cloud.
The whole idea is that they’re taking the integration burden off the customers, so that the customers can integrate their applications with Workday, without having to do any work on the customer end of the connection. This is a huge portion of the unfolding software-as-a-service story.
As we wind the clock forward, we’re going to see more customers wanting to use on-demand style applications, and wanting integration to be solved in an on-demand way. They don’t want to build all these integrations again. You can also take this one step further. We’ve seen a lot of our enterprise customers, as they think about rolling out big SOA initiatives, are saying, “Maybe, we should really model ourselves as a mini software-as-a-service to our own internal organizations.”
if we are going to virtualize storage and processing power, we want to virtualize integration. It’s not something that is being rebuilt again and again and again by different companies or different departments within different companies. Let’s really start to move to a hosted model for us, and, as you say, these can be federated in a very coherent way. What’s new now is that the underlying technologies and standards can actually support that model. So, while this model might have been a pipe dream five or six years ago, today it’s reality, and the technologies and capabilities are there to do it.
As the Web 2.0 generation gets into the enterprise, they’re going to have a very different view of how things should be done. They want it done the way that they have experienced this medium as teenagers. They’ll say, “What do you mean you can’t do it the way I want to do it?” I certainly hope that that’s the way it turns out, because we are just about due for another major innovation in the app development life-cycle.
Read a full transcript of the discussion. Listen to the podcast. Sponsor: Cape Clear Software.
As the use of Enterprise 2.0 mashups sweeps the IT industry, the concept of converging enterprise services has expanded to hosted munging of business applications and back-office functions.
Why not extend SOA itself by embracing more integration services that help vendors, ISVs, and service providers bring more elements of business processes together, too?
The budding notion of "integration-as-a-service" allows enterprise business leaders to "shop around" for their services, regardless of hosting, and opens up the prospect for a thriving new ecology of services and integration models for mission critical activities. The advancement to SOA for many companies may well be accelerated by more choices on means of connection, both inside and outside the organization's own IT boundaries.
I recently conducted a sponsored BriefingsDirect podcast discussion with Annrai O'Toole, CEO of Cape Clear Software, on the eye-opening prospects for integration as a service. Early adopters are already outsourcing aspects of integration. The implications are staggering: Business operators and entrepreneurs create and amend complex processes and workflows through a simple point and click interface on someone else's infrastructure. Pay by the use or general subscription. Retain control over data and ID management.
Here are some excerpts:
A couple of factors are driving this. First, it’s the whole technology maturity thing. Six or seven years ago, the standards around Web services were in their infancy, and people didn’t have a lot of experience with them. Because they were young, unproven, untested, and lacking in key bits of functionality, people didn’t really want to go there. Technology is one element of it, but there are a few more important elements driving it as well.
One is a secular trend toward simplicity and flexibility. At some levels, this has been driven by teams through virtualization. Storage and processing power are being very quickly virtualized. Applications are being virtualized, with software-as-a-service on demand. There is a long-term shift by customers, who are saying, “We don’t want to own complex infrastructure anymore. We’ve been there, and done that. We want something else.”
We had an RFP come in – and this isn’t all that unusual – from someone looking to do a big SOA initiative. It was – and I’m not joking -- a 111-page RFP.
Customers look at the choices available to them, and say, “Do we want to do all this big SOA integration on our own by buying these complex things, or are we prepared to look at alternatives? And, do those alternatives have any reality?” They do, and many companies are shying away from these big, complex initiatives.
You can sit in a room with a bunch of executives, both from the business and IT segments and, say, “Hosted integration is a good idea,” and they’ll know that. We’ve got some proof points around it. Most notably, one of our marquee customers in the software-as-a-service base is Workday. The PeopleSoft founders got together to rebuild an ERP application, but this time on a hosted basis.
We’ve seen two fundamental preferences here, and there are two options for what you want to host. The first option we would broadly categorize as very loosely coupled data transformation. A lot of the things that people need to solve in terms of integration problems are really data transformation. How do I take payroll information from one provider, transform it, and send it down to another provider? Most people can deal with that. Most people can wrap their head around how that can be done in a hosted manner. What’s involved there is that it’s loosely coupled and it’s data. It’s ultimately some kind of XML or it gets converted into XML somewhere along the line.
The next thing is a step up from that. Now that I can get information between these things, do I want to have some orchestrations or some kind of inter-company business processes? It’s not just getting data from A to B, but it’s, “I want to get data from A to B, and then I want to call C, and when C has completed its job, then I want to call D, and when that’s complete, the whole thing is done.” That’s next level of complexity, and it involves a more sophisticated approach. But, both of them are possible and both are in operation today. As far as what customers are going to go for, I think they’ll be happy to do data transformation initially, and when that’s really working for them, they might be prepared to take the next step and host business processes in the cloud.
The whole idea is that they’re taking the integration burden off the customers, so that the customers can integrate their applications with Workday, without having to do any work on the customer end of the connection. This is a huge portion of the unfolding software-as-a-service story.
As we wind the clock forward, we’re going to see more customers wanting to use on-demand style applications, and wanting integration to be solved in an on-demand way. They don’t want to build all these integrations again. You can also take this one step further. We’ve seen a lot of our enterprise customers, as they think about rolling out big SOA initiatives, are saying, “Maybe, we should really model ourselves as a mini software-as-a-service to our own internal organizations.”
if we are going to virtualize storage and processing power, we want to virtualize integration. It’s not something that is being rebuilt again and again and again by different companies or different departments within different companies. Let’s really start to move to a hosted model for us, and, as you say, these can be federated in a very coherent way. What’s new now is that the underlying technologies and standards can actually support that model. So, while this model might have been a pipe dream five or six years ago, today it’s reality, and the technologies and capabilities are there to do it.
As the Web 2.0 generation gets into the enterprise, they’re going to have a very different view of how things should be done. They want it done the way that they have experienced this medium as teenagers. They’ll say, “What do you mean you can’t do it the way I want to do it?” I certainly hope that that’s the way it turns out, because we are just about due for another major innovation in the app development life-cycle.
Read a full transcript of the discussion. Listen to the podcast. Sponsor: Cape Clear Software.
Sunday, July 8, 2007
SOA Insights analysts probe Software AG's webMethods buy, wikis for SOA governance, and SOA hype curves
Read a full transcript of the discussion.
How good of a match-up was the recent Software AG acquisition of WebMethods? Was is strictly a geographical sales force synergy? Or will webMethods become the de facto R&D arm of Software AG while the parent firm's legacy cash flow sustains the movement toward SOA? Are the mutual product sets well aligned to provide a fuller SOA suite offering? All of the above?
We posed these and other questions to our panel of independent IT industry analysts in a recent BriefingsDirect SOA Insights Edition roundtable podcast discussion. We also delve into the ongoing heavy-breathing between SOA and Web 2.0. Should governance by done by wikis, for example? Is this mashup of SOA and Web 2.0 a weekend dalliance? Or a love affair for life?
Lastly, we sink our collective analyst teeth into the notion that SOA -- gasp! -- is being hyped too much. Some of us actually thing the opposite.
So set your SOA compass to "I" for insights and join us for another 50-minute discussion. Feel free to listen, subscribe via iTunes (search on BriefingsDirect), or peruse the full transcript.
Not a SOA junkie? Well then just take a peek at some of the highlights here.
Our analyst panel for this edition of the podcasts consists of noted IT industry analysts and practitioners Steve Garone, Joe McKendrick, Jim Kobielus, Tony Baer, and Todd Biske. I was your host and moderator.
Here are some excerpts:
On SAG-webMethods ...
I think that webMethods has been looking for an exit strategy for some time, because basically they're trying to build up their SOA platform story. The fact is that large corporate customers are going to be nervous with a $200 million company. They’re probably a lot more comfortable with a company that’s closer to one billion, if they're looking for a platform play.
One of the challenges that will be before Software AG, and I think an indicator as to whether they are successfully getting the message out to their customers, is how they handle this transition with BPM. Obviously, having an internal product is going to be a lot more attractive than having to partner for it.
It’s pretty clear that from a geographic standpoint it’s very complementary. Actually, it’s more complementary from a product standpoint than many there have been there willing take credit for. Software AG ... is very strong on legacy modernization of the whole mainframe-based setup products for development, databases, and so forth.
WebMethods is very strong on integration, BPM, and the whole SOA stack registries. There is some redundancy with Software AG’s products, such as the whole Crossvision Suite, but I think that from a technological standpoint webMethods is stronger on BPM, the repository, and all of those SOA components than the company that’s acquiring it. There definitely are a lot of synergies there.
So, you’re saying that webMethods is ahead of its time, and Software AG might be behind the times, and so together they are going to be on time?
This smacks of a good sales and channel match-up, and they might run webMethods as a subsidiary for some time. Then there's also this balance-sheet issue, where Software AG has recurring revenue. It’s got an old cash cow to continue to milk, and that gives webMethods an opportunity to be funded and financed -- without the vagaries of a quarterly report to Wall Street -- to pursue the larger brass ring here, which is SOA.
On SOA and Web 2.0 mashups ...
Let’s just leave the Web 2.0 definition off the table and look at the issue of any of these new activities, whether it’s social networking or rich Internet application interfaces or whether it’s taking advantage of more semantics and BPEL as a process relating to Web activities instead of just as a publishing medium. Let’s just say, "All of the above" for defining Web 2.0 and how this relates to SOA.
Gee, maybe wikis would be a good concept for how people manage their SOA services. It's sort of an open source, open collaboration approach to policy and use of services and their agreements.
Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.
In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.
I don’t know that you really want a wiki-style collaboration for governance. ... Even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.
So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally.
It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.
Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.
On SOA hype ...
There are still a lot of of companies that just don’t know how to do cultural change. It’s not an easy thing to do. We hyped SOA a lot from the IT perspective, and a lot of the IT managers certainly may be growing tried of hearing about it, but haven't done anything to actually start that process of cultural change.
Is it really adopted by the business side and do they understand what it means and how it can impact our business? If they aren't having those communications, we haven’t really changed anything, and that means they’re still open for that message to continue, and to increase.
I think the SOA hype is pretty high, but I think that it's difficult to sell to decision-makers due to two factors: 1) the degree to which cultural change needs to take place, and 2) as time has progressed through this decade so far we’ve seen greater caution in IT departments because of shrinking budgets. So, the hype is high, but it needs to be sustained longer with messaging that’s going to be more aligned with business goals, rather than technology.
It could be that companies are being run more by the accountants -- of, for, and by the accountants -- and therefore the vision around IT is not getting through to them, and the purse strings are not opening up. Is that possible?
I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.
Another hour not wasted.
Listen to the entire podcast, or read the full transcript for more IT analysis and SOA insights. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media IT content production and distribution.
How good of a match-up was the recent Software AG acquisition of WebMethods? Was is strictly a geographical sales force synergy? Or will webMethods become the de facto R&D arm of Software AG while the parent firm's legacy cash flow sustains the movement toward SOA? Are the mutual product sets well aligned to provide a fuller SOA suite offering? All of the above?
We posed these and other questions to our panel of independent IT industry analysts in a recent BriefingsDirect SOA Insights Edition roundtable podcast discussion. We also delve into the ongoing heavy-breathing between SOA and Web 2.0. Should governance by done by wikis, for example? Is this mashup of SOA and Web 2.0 a weekend dalliance? Or a love affair for life?
Lastly, we sink our collective analyst teeth into the notion that SOA -- gasp! -- is being hyped too much. Some of us actually thing the opposite.
So set your SOA compass to "I" for insights and join us for another 50-minute discussion. Feel free to listen, subscribe via iTunes (search on BriefingsDirect), or peruse the full transcript.
Not a SOA junkie? Well then just take a peek at some of the highlights here.
Our analyst panel for this edition of the podcasts consists of noted IT industry analysts and practitioners Steve Garone, Joe McKendrick, Jim Kobielus, Tony Baer, and Todd Biske. I was your host and moderator.
Here are some excerpts:
On SAG-webMethods ...
I think that webMethods has been looking for an exit strategy for some time, because basically they're trying to build up their SOA platform story. The fact is that large corporate customers are going to be nervous with a $200 million company. They’re probably a lot more comfortable with a company that’s closer to one billion, if they're looking for a platform play.
One of the challenges that will be before Software AG, and I think an indicator as to whether they are successfully getting the message out to their customers, is how they handle this transition with BPM. Obviously, having an internal product is going to be a lot more attractive than having to partner for it.
It’s pretty clear that from a geographic standpoint it’s very complementary. Actually, it’s more complementary from a product standpoint than many there have been there willing take credit for. Software AG ... is very strong on legacy modernization of the whole mainframe-based setup products for development, databases, and so forth.
WebMethods is very strong on integration, BPM, and the whole SOA stack registries. There is some redundancy with Software AG’s products, such as the whole Crossvision Suite, but I think that from a technological standpoint webMethods is stronger on BPM, the repository, and all of those SOA components than the company that’s acquiring it. There definitely are a lot of synergies there.
So, you’re saying that webMethods is ahead of its time, and Software AG might be behind the times, and so together they are going to be on time?
This smacks of a good sales and channel match-up, and they might run webMethods as a subsidiary for some time. Then there's also this balance-sheet issue, where Software AG has recurring revenue. It’s got an old cash cow to continue to milk, and that gives webMethods an opportunity to be funded and financed -- without the vagaries of a quarterly report to Wall Street -- to pursue the larger brass ring here, which is SOA.
On SOA and Web 2.0 mashups ...
Let’s just leave the Web 2.0 definition off the table and look at the issue of any of these new activities, whether it’s social networking or rich Internet application interfaces or whether it’s taking advantage of more semantics and BPEL as a process relating to Web activities instead of just as a publishing medium. Let’s just say, "All of the above" for defining Web 2.0 and how this relates to SOA.
Gee, maybe wikis would be a good concept for how people manage their SOA services. It's sort of an open source, open collaboration approach to policy and use of services and their agreements.
Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.
In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.
I don’t know that you really want a wiki-style collaboration for governance. ... Even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.
So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally.
It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.
Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.
On SOA hype ...
There are still a lot of of companies that just don’t know how to do cultural change. It’s not an easy thing to do. We hyped SOA a lot from the IT perspective, and a lot of the IT managers certainly may be growing tried of hearing about it, but haven't done anything to actually start that process of cultural change.
Is it really adopted by the business side and do they understand what it means and how it can impact our business? If they aren't having those communications, we haven’t really changed anything, and that means they’re still open for that message to continue, and to increase.
I think the SOA hype is pretty high, but I think that it's difficult to sell to decision-makers due to two factors: 1) the degree to which cultural change needs to take place, and 2) as time has progressed through this decade so far we’ve seen greater caution in IT departments because of shrinking budgets. So, the hype is high, but it needs to be sustained longer with messaging that’s going to be more aligned with business goals, rather than technology.
It could be that companies are being run more by the accountants -- of, for, and by the accountants -- and therefore the vision around IT is not getting through to them, and the purse strings are not opening up. Is that possible?
I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.
Another hour not wasted.
Listen to the entire podcast, or read the full transcript for more IT analysis and SOA insights. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media IT content production and distribution.
SOA demands a new 80-20 rule for application development
Services oriented architectures (SOAs) are not only forcing a new way of looking at how to construct applications and composite services -- SOA is now changing the meaning of what custom applications are and how they will be acquired. And this change has significant ramifications for IT developers, architects and operators as they seek a new balance between "packaged" and "custom" applications.
As more applications are broken down into modular component services, and as more services are newly created specifically for use and reuse in composited business services, the old 80-20 rule needs to make way for a new 80-20 rule.
The old 80-20 rule for development (and there are variations) holds that 80 percent of the time and effort of engineering an application goes into the 20 percent requiring the most customization. Perhaps that's why we have the 90-10 rule, too, which hold that 90 percent of the execution time of a computer program is spent executing 10 percent of the code!
SOA skews the formula by making more elements of an application's stated requirements readily available as a service. As those services are acquired from many sources, including more specialized ones (from third-party developers or vendors), a funny thing happens.
At first the amount of needed customization is high -- maybe 80 percent (a perversion of the old rule) -- either because there are not many services available, or because the services are too general and not specific to a specialized vertical industry or niche function.
Then, over time, with investment, the balance shifts toward the 50-50 point, and reuse forms a majority of a composite applications or business process, even for highly specialized applications. These composited functions then become business-focused service frameworks, to then be reused and adjusted. Those architects that gain experience within business niches and verticals to create such frameworks can make significant reuse of the services.
They, and their employers, enjoy tipping points where the majority of their development comes from existing services. The higher they can drive the percentage of reuse, the more scale and productivity they gain. They become the go-to organization for cost-efficient applications in a specific industry, or for specialized business processes.
These organizations benefit from the new 80-20 rule of SOA: The last 20 percent of customization soon takes only 50 percent of the total time to value. The difference from 80 percent is huge in terms of who does SOA best for specialized business processes. And it makes the decision all the more difficult over how to best exploit SOA: internally, or via third parties, integrators, or vendors.
It used to be that the large packaged applications vendors, like SAP, Oracle and Microsoft, used similar logic to make their vast suites of applications must-haves for enterprises. They exploited reusable objects and components to create commodity-level business functional suites that were soon deemed best bought and loaded, and not made, company by company, across the globe.
But with SOA the same efficiencies of scale and reuse can be brought to much more specific and customized applications. And those applications, if implemented as web services, can be ripped up, shifted, mashed adjusted and changed rapidly, if you know enough about them. The flexible orchestration of loosely coupled services means that development teams can better meet business’s changing needs.
A big question for me is which development teams will be benefiting most from the new 80-20 rule SOA activities? After attending the recent IBM Innovate conference in May, it's clear that specialization in SOA-related business processes via services frameworks will change the nature of custom application development. IBM and its services divisions are banking that the emerging middle ground between packaged applications and good-old customization opens up a new category they and their partners can quickly dominate with such offerings as WebSphere Business Services Fabric.
If IT departments inside of enterprises and their developer corps can not produce such flexible, efficient services-driven business processes, their business executives will evaluate alternatives as they seek agility. Such a market, in essence, forces a race to SOA proficiency and economy. That race is now getting under way, pitting traditional application providers, internal custom developers, vertical application packagers, and systems integrators against one another.
Even as businesses examine services-oriented efficiency and SOA benefits, they will also need to consider who owns the innovation that comes when you develop a service framework that enables a vertical business process. It would be clearly dangerous for any company to outsource its process innovation, and to lose intellectual property control over their core differentiating processes, either to a consulting firm that would develop the customizations, or to a software vendor that would productize it as a framework.
Executives will need to balance the enticements of outside organizations with a powerful SOA arsenal against the need to innovate in private, and to keep those innovations inside. They must be able to use what's available on an acquired basis to compete -- and which benefits from a common structural approach of highly granular reuse -- but not so much that they lose their unique competitive advantage.
And this brings us back to the new 80-20 rule for SOA, which also holds that companies need to retain 80 percent control over the 20 percent of the business processes that make it most competitive in its own markets. The move to a services environment via outside parties alone risks violating this rule. Therefore, internal IT must advance in SOA proficiencies as well, if only to be able to keep up with the third parties that will be servicing the competition.
We really have entered a race to SOA benefits and efficiencies. Time to lace up your running shoes once again.
As more applications are broken down into modular component services, and as more services are newly created specifically for use and reuse in composited business services, the old 80-20 rule needs to make way for a new 80-20 rule.
The old 80-20 rule for development (and there are variations) holds that 80 percent of the time and effort of engineering an application goes into the 20 percent requiring the most customization. Perhaps that's why we have the 90-10 rule, too, which hold that 90 percent of the execution time of a computer program is spent executing 10 percent of the code!
SOA skews the formula by making more elements of an application's stated requirements readily available as a service. As those services are acquired from many sources, including more specialized ones (from third-party developers or vendors), a funny thing happens.
At first the amount of needed customization is high -- maybe 80 percent (a perversion of the old rule) -- either because there are not many services available, or because the services are too general and not specific to a specialized vertical industry or niche function.
Then, over time, with investment, the balance shifts toward the 50-50 point, and reuse forms a majority of a composite applications or business process, even for highly specialized applications. These composited functions then become business-focused service frameworks, to then be reused and adjusted. Those architects that gain experience within business niches and verticals to create such frameworks can make significant reuse of the services.
They, and their employers, enjoy tipping points where the majority of their development comes from existing services. The higher they can drive the percentage of reuse, the more scale and productivity they gain. They become the go-to organization for cost-efficient applications in a specific industry, or for specialized business processes.
These organizations benefit from the new 80-20 rule of SOA: The last 20 percent of customization soon takes only 50 percent of the total time to value. The difference from 80 percent is huge in terms of who does SOA best for specialized business processes. And it makes the decision all the more difficult over how to best exploit SOA: internally, or via third parties, integrators, or vendors.
It used to be that the large packaged applications vendors, like SAP, Oracle and Microsoft, used similar logic to make their vast suites of applications must-haves for enterprises. They exploited reusable objects and components to create commodity-level business functional suites that were soon deemed best bought and loaded, and not made, company by company, across the globe.
But with SOA the same efficiencies of scale and reuse can be brought to much more specific and customized applications. And those applications, if implemented as web services, can be ripped up, shifted, mashed adjusted and changed rapidly, if you know enough about them. The flexible orchestration of loosely coupled services means that development teams can better meet business’s changing needs.
A big question for me is which development teams will be benefiting most from the new 80-20 rule SOA activities? After attending the recent IBM Innovate conference in May, it's clear that specialization in SOA-related business processes via services frameworks will change the nature of custom application development. IBM and its services divisions are banking that the emerging middle ground between packaged applications and good-old customization opens up a new category they and their partners can quickly dominate with such offerings as WebSphere Business Services Fabric.
If IT departments inside of enterprises and their developer corps can not produce such flexible, efficient services-driven business processes, their business executives will evaluate alternatives as they seek agility. Such a market, in essence, forces a race to SOA proficiency and economy. That race is now getting under way, pitting traditional application providers, internal custom developers, vertical application packagers, and systems integrators against one another.
Even as businesses examine services-oriented efficiency and SOA benefits, they will also need to consider who owns the innovation that comes when you develop a service framework that enables a vertical business process. It would be clearly dangerous for any company to outsource its process innovation, and to lose intellectual property control over their core differentiating processes, either to a consulting firm that would develop the customizations, or to a software vendor that would productize it as a framework.
Executives will need to balance the enticements of outside organizations with a powerful SOA arsenal against the need to innovate in private, and to keep those innovations inside. They must be able to use what's available on an acquired basis to compete -- and which benefits from a common structural approach of highly granular reuse -- but not so much that they lose their unique competitive advantage.
And this brings us back to the new 80-20 rule for SOA, which also holds that companies need to retain 80 percent control over the 20 percent of the business processes that make it most competitive in its own markets. The move to a services environment via outside parties alone risks violating this rule. Therefore, internal IT must advance in SOA proficiencies as well, if only to be able to keep up with the third parties that will be servicing the competition.
We really have entered a race to SOA benefits and efficiencies. Time to lace up your running shoes once again.
Subscribe to:
Posts (Atom)