On BNET: Turn your iPhone into an air mouse
BNET Business Network:
BNET
TechRepublic
ZDNet

Category: Web Services

November 16th, 2009

BriefingsDirect analysts discuss business commerce clouds: Wave of the future or old wine in a new bottle?

Posted by Dana Gardner @ 9:30 am

Categories: Amazon, Cloud computing, Enterprise 2.0, Google, Government, HP, IBM, Microsoft, Oracle, Podcasts, SAP, SOA Governance, SaaS, Security, Software Development, Software Infrastructure, Web Services, convergence, governance, management

Tags: Business Process, Supply Chain, Network, Wine, Cloud, Business Commerce Cloud, Age-old, RollStream, Operational Planning, EDI

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript, or download a copy. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint’s ActiveVOS at www.activevos.com/insight.

Welcome to the latest BriefingsDirect Analyst Insights Edition, Vol. 46. Our topic for this episode of BriefingsDirect Analyst Insights Edition centers on “business commerce clouds.” As the general notion of cloud computing continues to permeate the collective IT imagination, an offshoot vision holds that multiple business-to-business (B2B) players could use the cloud approach to build extended business process ecosystems.

It’s sort of like a marketplace in the cloud on steroids, on someone else’s servers, perhaps to engage on someone’s business objectives, and maybe even satisfy some customers along the way. It’s really a way to make fluid markets adapt at Internet speed, at low cost, to business requirements, as they come and go.

I, for one, can imagine a dynamic, elastic, self-defining, and self-directing business-services environment that wells up around the needs of a business group or niche, and then subsides when lack of demand dictates. Here’s an early example of how it works, in this case for food recall.

The concept of this business commerce cloud was solidified for me just a few weeks ago, when I spoke to Tim Minahan, chief marketing officer at Ariba. I’ve invited Tim to join us to delve into the concept, and the possible attractions, of business commerce clouds. We’re also joined by this episode’s IT industry analyst guests: Tony Baer, senior analyst at Ovum; Brad Shimmin, principal analyst at Current Analysis; Jason Bloomberg, managing partner at ZapThink; JP Morgenthal, independent analyst and IT consultant, and Sandy Kemsley, independent IT analyst and architect. The discussion is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

This periodic discussion and dissection of IT infrastructure related news and events, with a panel of industry analysts and guests, comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS, visual orchestration system, and through the support of TIBCO Software.

Here are some excerpts:

Minahan: When we talk about business commerce clouds, what we’re talking about is leveraging the cloud architecture to go to the next level. When folks traditionally think of the cloud or technology, they think of managing their own business processes. But, as we know, if we are going to buy, sell, or manage cash, you need to do that with at least one, if not more, third parties.

The business commerce cloud leverages cloud computing to deliver three things. It delivers the business process application itself as a cloud-based or a software-as-a-service (SaaS)-based service. It delivers a community of enabled trading partners that can quickly be discovered, connected to, and enable collaboration with them.

And, the third part is around capabilities –the ability to dial up or dial down, whether it be expertise, resources, or other predefined best practice business processes — all through the cloud.

… Along the way, what we [at Ariba] found was that we were connecting all these parties through a shared network that we call the Ariba Supplier Network. We realized we weren’t just creating value for the buyers, but we were creating value for the sellers.

They were pushing us to develop new ways for them to create new business processes on the shared infrastructure — things like supply chain financing, working capital management, and a simple way to discover each other and assess who their next trading partners may be.

… In the past year, companies have processed $120 billion worth of purchased transactions and invoices over this network. Now, they’re looking at new ways to find new trading partners — particularly as the incidence of business bankruptcies are up — as well as extend to new collaborations, whether it be sharing inventory or helping to manage their cash flow.

Baer: I think there are some very interesting possibilities, and in certain ways this is very much an evolutionary development that began with the introduction of EDI 40 or 45 years ago.

Actually, if you take a took at supply-chain practices among some of the more innovative sectors, especially consumer electronics, where you deal with an industry that’s very volatile both by technology and consumer taste, this whole idea of virtualizing the supply chain, where different partners take on greater and greater roles in enabling each other, is very much a direct follow on to all that.

Roughly 10 years ago, when we were going though the Internet 1.0 or the dot-com revolution, we started getting into these B2B online trading hubs with the idea that we could use the Internet to dynamically connect with business partners and discover them. Part of this really seemed to go against the trend of supply-chain practice over the previous 20 years, which was really more to consolidate on a known group of partners as opposed to spontaneously connecting with them.

Shimmin: … I look at this as an enabler, in a positive way. What the cloud does is allow what Tim was hinting at — with more spontaneity, self-assembly, and visibility into supply chains in particular — that you didn’t really get before with the kind of locked down approach we had with EDI.

That’s why I think you see so many of those pure-play EDI vendors like GXS, Sterling, SEEBURGER, Inovis, etc. not just opening up to the Internet, but opening up to some of the more cloudy standards like cXML and the like, and really doing a better job of behaving like we in the 2009-2010 realm expect a supply chain to behave, which is something that is much more open and much more visible.

Kemsley: … I think it has huge potential, but one of the issues that I see is that so many companies are afraid to start to open up, to use external services as part of their mission-critical businesses, even though there is no evidence that a cloud-based service is any less reliable than their internal services. It’s just that the failures that happen in the cloud are so much more publicized than their internal failures that there is this illusion that things in the cloud are not as stable.

There are also security concerns as well. I have been at a number of business process management (BPM) conferences in the last month, since this is conference season, and that is a recurring theme. Some of the BPM vendors are putting their products in the cloud so that you can run your external business processes purely in the cloud, and obviously connect to cloud-based services from those.

A lot of companies still have many, many problems with that from a security standpoint, even though there is no evidence that that’s any less secure than what they have internally. So, although I think there is a lot of potential there, there are still some significant cultural barriers to adopting this.

Minahan: … The cloud provider, because of the economies of scale they have, oftentimes provides better security and can invest more in security — partitioning, and the like — than many enterprises can deliver themselves. It’s not just security. It’s the other aspects of your architectural performance.

Bloomberg: … I am coming at it from a skeptic’s perspective. It doesn’t sound like there’s anything new here. … We’re using the word “cloud” now, and we were talking about “business webs.” I remember business webs were all the rage back when Ariba had their first generation of offerings, as well as Commerce One and some of the other players in that space.

Age-old challenges

The challenges then are still the challenges now. Companies don’t necessarily like doing business with other organizations that they don’t have established relationships with. The value proposition of the central marketplaces has been hammered out now. If you want to use one, they’re already out there and they’re already matured. If you don’t want to use one, putting the word “cloud” on it is not going to make it any more appealing.

Morgenthal: … Putting additional information in the cloud and making value out of that add some overall value to the cost of the information or the cost of running the system, so you can derive a few things. But, ultimately, the same problems that are needed to drive a community working together, doing business together, exchanging product through an exchange are still there.

… What’s being done through these environments is the exchange of money and goods. And, it’s the overhead related to doing that, that makes this complex. RollStream is another startup in the area that’s trying to make waves by simplifying the complexities around exchanging the partner agreements and doing the trading partner management using collaborative capabilities. Again, the real complexity is the business itself. It’s not even the business processes. The data is there.

… Technology is a means to an end. The end that’s got to get fixed here isn’t an app fix. It’s a community fix. It’s a “how business gets done” fix. Those processes are not automated. Those are human tasks.

Minahan: … As it applies to the cloud and the commerce cloud, what’s interesting here is the new services that can be available. It’s different. It’s not just about discovering new trading partners. It’s about creating efficiencies and more effective commerce processes with those trading partners.

I’ll give you a good example. I mentioned before about the Ariba Network with $111 billion worth of transactions and invoices being transferred over this every year for the past 10 years. That gives us a lot of intelligence that new companies are coming on board.

An example would be The Receivables Exchange. Traditionally sellers, if they wanted to get their cash fast, could factor the receivables at $0.25 on the dollar. This organization recognized the value of the information that was being transacted over this network and was able to create an entirely new service.

They were able to mitigate the risk, and provide supply chain financing at a much lower basis — somewhere between two to four percent by using the historical information on those trading relationships, as well as understanding the stability of the buyer.

What we’re seeing with our customers is that the real benefits of the cloud come in three areas: productivity, agility, and innovation.

Because folks are in a shared infrastructure here that can be continually introduced, new services can be dialed up and dialed down. It’s a lot different than a rigid EDI environment or just a discovery marketplace. … What we’re seeing with our customers is that the real benefits of the cloud come in three areas: productivity, agility, and innovation.

… When folks talk about cloud, they really think about the infrastructure, and what we are talking about here is a business service cloud.

Gartner calls it the business process utility, which ultimately is a form of technology-enabled business process outsourcing. It’s not just the technology. The technology or the workflow is delivered in the cloud or as a web-based service, so there is no software, hardware, etc. for the trading partners to integrate, to deploy or maintain. That was the bane of EDI private VANs.

The second component is the community. Already having an established community of trading partners who are actually conducting business and transactions is key. I agree with the statement that it comes down to the humans and the companies having established agreements. But the point is that it can be built upon a large trading network that already exists.

The last part, which I think is missing here, and that’s so interesting about the business commerce cloud, are the capabilities. It’s the ability for either the solution provider or other third parties to deliver skills, expertise, and resources into the cloud as well as a web-based service.

It’s also the information that can be garnered off the community to create new web-based services and capabilities that folks either don’t have within their organization or don’t have the ability or wherewithal to go out and develop and hire on their own. There is a big difference between cloud computing and these business service clouds that are growing.

Shimmin: … The fuller picture is to look at this as a combination of [Apple App Store] and the Amazon marketplace. That’s where I think you will see the most success with these commerce clouds — a very specific community of like-minded suppliers and purchasers that want to get together and open their businesses up to one another.

… A community of companies wants to be able to come together affordably, so that the SMB can on-board an exchange at an affordable rate. That’s really been the problem with most of these large-scale EDI solutions in the past. It’s so expensive to bring on the smaller players that they can’t play.

… When you have that sort of like-mindedness, you have the wherewithal to collaborate. But, the problem has always been finding the right people, getting to that knowledge that people have, and getting them to open it up. That’s where the social networking side of this comes in. That’s where I see the big EDI guns I was talking about and the more modernized renditions opening up to this whole Google Wave notion of what collaboration means in a social networking context.

That’s one key area — being able to have the collaboration and social networking during the modeling of the processes.

Minahan: … We’re seeing that already through the exchange that we have amongst our customers or around our solutions. We’re also seeing that in a lot of the social networking communities that we participate in around the exchange of best practices. The ability to instantiate that into reusable workflows is something that’s certainly coming.

Folks are always asking these days, “We hear a lot about this cloud. What business processes or technologies should we put in the cloud?” When you talk about that, the most likely ones are inter-enterprise, whether they be around commerce, talent management, or customer management, it’s what happens between enterprises where a shared infrastructure makes the most sense.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript, or download a copy. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint’s ActiveVOS at www.activevos.com/insight.

November 16th, 2009

ZapThink explores the four stages of SOA governance that lead to business agility

Posted by Dana Gardner @ 7:09 am

Categories: Agile Development, Application Lifecycle Management, Cloud computing, HP, IBM, IT Management, IT Service Management, ITIL, Microsoft, Progress Software, SOA, SOA Governance, SOA architect, Software Development, Web Services, database, datacenters, governance, management

Tags: ZapThink LLC, Policy, SOA, SOA Governance, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Dana Gardner

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

By Jason Bloomberg

For several years now, ZapThink has spoken about SOA governance “in the narrow” vs. SOA governance” in the broad.” SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the service lifecycle.

When vendors try to sell you SOA governance gear, they’re typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

In both our Licensed ZapThink Architect Boot Camp as well as our newer SOA and Cloud Governance Course, we also point out how governance typically involves human communication-centric activities like architecture reviews, human management, and people deciding to comply with policies. We point out this human context for governance to contrast it to the technology context that inevitably becomes the focus of SOA governance in the narrow. There is an important technology-centric SOA governance story to be told, of course, as long as it’s placed into the greater governance context.

One question we haven’t yet addressed in depth, however, is how these two contrasts — narrow vs. broad, human vs. technology — fit together. Taking a closer look, there’s an important trend taking shape, as organizations mature their approach to SOA governance, and with it, the overall SOA effort. Following this trend to its natural conclusion highlights some important facts about SOA, and can help organizations understand where they want to end up as their SOA initiative reaches its highest levels of maturity.

Introducing the SOA governance grid

Whenever faced with to orthogonal contrasts, the obvious thing to do is put them in a grid. Let’s see what we can learn from such a diagram:

The ZapThink SOA governance grid

First, let’s take a look at what each square contains, starting with the lower left corner and moving clockwise, because as we’ll see, that’s the sequence that corresponds best to increasing levels of SOA maturity.

1. Human-centric SOA governance in the narrow

As organizations first look at SOA and the governance challenge it presents, they must decide how they want to handle various governance issues. They must set up a SOA governance board or other committee to make broad SOA policy decisions. We also recommend setting up a SOA Center of Excellence to coordinate such policies across the whole enterprise.

These policy decisions initially focus on how to address business requirements, how to assemble and coordinate the SOA team, and what the team will need to do as they ramp up the SOA effort. The output of such SOA governance activities tend to be written documents and plenty of conversations and meetings.

The tools architects use for this stage are primarily communication-centric, namely word processors and portals and the like. But this stage is also when the repository comes into play as a place to put many such design time artifacts, and also where architects configure design time workflows for the SOA team. Technology, however, plays only a supporting role in this stage.

2. Technology-centric SOA governance in the narrow

As the SOA effort ramps up, the focus naturally shifts to technology. Governance activities center on the registry/repository and the rest of the SOA governance gear. Architects roll up their sleeves and hammer out technology-centric policies, preferably in an XML format that the gear can understand. Representing certain policies as metadata enables automated communication and enforcement of those policies, and also makes it more straightforward to change those policies over time.

This stage is also when run time SOA governance begins. Certain policies must be enforced at run time, either within the underlying runtime environment, in the management tool, or in the security infrastructure. At this point the SOA registry becomes a central governance tool, because it provides a single discovery point for run time policies. Tool-based interoperability also rises to the fore, as WS-I compliance, as well as compliance with the Governance Interoperability Framework or the CentraSite Community become essential governance policies.

3. Technology-centric SOA governance in the broad

The SOA implementation is up and running. There are a number of services in production, and their lifecycle is fully governed through hard work and proper architectural planning. Taking the SOA approach to responding to new business requirements is becoming the norm. So, when new requirements mean new policies, it’s possible to represent some of them as metadata as well, even though the policies aren’t specific to SOA.

Such policies are still technology-centric, for example, security policies or data governance policies or the like. Fortunately, the SOA governance infrastructure is up to the task of managing, communicating, and coordinating the enforcement of such policies. By leveraging SOA, it’s possible to centralize policy creation and communication, even for policies that aren’t SOA-specific.

Sometimes, in fact, new governance requirements can best be met with new services. For example, a new regulatory requirement might lead to a new message auditing policy. Why not build a service to take care of that? This example highlights what we mean by SOA governance in the broad. SOA is in place, so when a new governance requirement comes over the wall, we naturally leverage SOA to meet that requirement.

4. Human-centric SOA governance in the broad

This final stage is the most thought-provoking of all, because it represents the highest maturity level. How can SOA help with the human activities that form the larger picture of governance in the organization? Clearly, XML representations of technical policies aren’t the answer here. Rather, it’s how implementing SOA helps expand the governance role architecture plays in the organization. It’s a core best practice that architecture should drive IT governance. When the organization has adopted SOA, then SOA helps to inform best practices for IT governance overall.

The impact of SOA on enterprise architecture (EA) is also quite significant. Now that EAs increasingly realize that SOA is a style of EA, EA governance is becoming increasingly service-orientated in form as well. It is at this stage that part of the SOA governance value-proposition benefits the business directly, by formalizing how the enterprise represents capabilities consistent with the priorities of the organization.

The ZapThink take

T
he big win to moving to the fourth stage is in how leveraging SOA approaches to formalize EA governance impacts the organization’s business agility requirement. In some ways business agility is like any other business requirement, in that proper business analysis can delineate the requirement to the point that the technology team can deliver it, the quality team can test for it, and the infrastructure can enforce it. But as we’ve written before, as an emergent property of the implementation, business agility is a different sort of requirement from more traditional business requirements in a fundamental way.

A critical part of achieving this business agility over time is to break down the business agility requirement into a set of policies, and then establish, communicate, and enforce those policies — in other words, provide business agility governance. Only now, we’re not talking about technology at all. We’re talking about transforming how the organization leverages resources in a more agile manner by formalizing its approach to governance by following SOA best practices at the EA level. Organizations must understand the role SOA governance plays in achieving this long-term strategic vision for the enterprise.

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.


SPECIAL PARTNER OFFER

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.


November 9th, 2009

Here's why text-based content access and management play crucial roles in real-time BI

Posted by Dana Gardner @ 2:27 pm

Categories: BI, Enterprise 2.0, Google, Government, HP, IBM, Podcasts, Software Development, Software Infrastructure, Web Services, business intelligence, content delivery network, database, management, search

Tags: Dana Gardner

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Kapow Technologies.

Text-based content and information from across the Web are growing in importance to businesses. The need to analyze web-based text in real-time is rising to where structured data was in importance just several years ago.

Indeed, for businesses looking to do even more commerce and community building across the Web, text access and analytics forms a new mother lode of valuable insights to mine.

As the recession forces the need to identify and evaluate new revenue sources, businesses need to capture such web data services for their business intelligence (BI) to work better, deeper, and faster.

In this podcast discussion, Part 3 of a series on web data services for BI, we discuss how an ecology of providers and a variety of content and data types come together in several use-case scenarios.

In Part 1 of our series we discussed how external data has grown in both volume and importance across the Internet, social networks, portals, and applications. In Part 2, we dug even deeper into how to make the most of web data services for BI, along with the need to share those web data services inferences quickly and easily.

Our panel now looks specifically at how near real-time text analytics fills out a framework of web data services that can form a whole greater than the sum of the parts, and this brings about a whole new generation of BI benefits and payoffs.

To help explain the benefits of text analytics and their context in web data services, we’re joined by Seth Grimes, principal consultant at Alta Plana Corp., and Stefan Andreasen, co-founder and chief technology officer at Kapow Technologies. The discussion is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Grimes: “Noise free” is an interesting and difficult concept when you’re dealing with text, because text is just a form of human communication. Whether it’s written materials, or spoken materials that have been transcribed into text, human communications are incredibly chaotic … and they are full of “noise.” So really getting to something that’s noise-free is very ambitious.

… It’s become an imperative to try to deal with the great volume of text — the fire hose, as you said — of information that’s coming out. And, it’s coming out in many, many different languages, not just in English, but in other languages. It’s coming out 24 hours a day, 7 days a week — not only when your business analysts are working during your business day. People are posting stuff on the web at all hours. They are sending email at all hours.

If you want to keep up, if you want to do what business analysts have been referring to as a 360-degree analysis of information, you’ve got to have automated technologies to do it.

… There are hundreds of millions of people worldwide who are on the Internet, using email, and so on. There are probably even more people who are using cell phones, text messaging, and other forms of communication.

If you want to keep up, if you want to do what business analysts have been referring to as a 360-degree analysis of information, you’ve got to have automated technologies to do it. You simply can’t cope with the flood of information without them.

Fortunately, the software is now up to the job in the text analytics world. It’s up to the job of making sense of the huge flood of information from all kinds of diverse sources, high volume, 24 hours a day. We’re in a good place nowadays to try to make something of it with these technologies.

Andreasen: … There is also a huge amount of what I call “deep web,” very valuable information that you have to get to in some other way. That’s where we come in and allow you to build robots that can go to the deep web and extract information.

… Eliminating noise is getting rid of all this stuff around the article that is really irrelevant, so you get better results.

The other thing around noise-free is the structure. … The key here is to get noise-free data and to get full data. It’s not only to go to the deep web, but also get access to the data in a noise-free way, and in at least a semi-structured way, so that you can do better text analysis, because text analysis is extremely dependent on the quality of data.

Grimes: … [There are] many different use-cases for text analytics. This is not only on the Web, but within the enterprise as well, and crossing the boundary between the Web and the inside of the enterprise.

Those use-cases can be the early warning of a Swine flu epidemic or other medical issues. You can be sure that there is text analytics going on with Twitter and other instant messaging streams and forums to try to detect what’s going on.

… You also have brand and reputation management. If someone has started posting something very negative about your company or your products, then you want to detect that really quickly. You want early warning, so that you can react to it really quickly.

We have some great challenges out there, but . . . we have great technologies to respond to those challenges.

We have a great use case in the intelligence world. That’s one of the earliest adopters of text analytics technology. The idea is that if you are going to do something to prevent a terrorist attack, you need to detect and respond to the signals that are out there, that something is pending really quickly, and you have to have a high degree of certainty that you’re looking at the right thing and that you’re going to react appropriately.

Text analytics actually predate BI. The basic approaches to analyzing textual sources were defined in the late ’50s. Actually, there is a paper from an IBM researcher from 1958, that defines BI as the analysis of textual sources.

…[Now] we want to take a subset of all of the information that’s out there in the so-called digital universe and bring in only what’s relevant to our business problems at hand. Having the infrastructure in place to do that is a very important aspect here.

Once we have that information in hand, we want to analyze it. We want to do what’s called information extraction, entity extraction. We want to identify the names of people, geographical location, companies, products, and so on. We want to look for pattern-based entities like dates, telephone numbers, addresses. And, we want to be able to extract that information from the textual sources.

Suitable technologies

All of this sounds very scientific and perhaps abstruse — and it is. But, the good message here is one that I have said already. There are now very good technologies that are suitable for use by business analysts, by people who aren’t wearing those white lab coats and all of that kind of stuff. The technologies that are available now focus on usability by people who have business problems to solve and who are not going to spend the time learning the complexities of the algorithms that underlie them.

Andreasen: … Any BI or any text analysis is no better than the data source behind it. There are four extremely important parameters for the data sources. One is that you have the right data sources.

There are so many examples of people making these kind of BI applications, text analytics applications, while settling for second-tier data sources, because they are the only ones they have. This is one area where Kapow Technologies comes in. We help you get exactly the right data sources you want.

The other thing that’s very important is that you have a full picture of the data. So, if you have data sources that are relevant from all kinds of verticals, all kinds of media, and so on, you really have to be sure you have a full coverage of data sources. Getting a full coverage of data sources is another thing that we help with.

Noise-free data

We already talked about the importance of noise-free data to ensure that when you extract data from your data source, you get rid of the advertisements and you try to get the major information in there, because it’s very valuable in your text analysis.

Of course, the last thing is the timeliness of the data. We all know that people who do stock research get real-time quotes. They get it for a reason, because the newer the quotes are, the surer they can look into the crystal ball and make predictions about the future in a few seconds.

The world is really changing around us. Companies need to look into the crystal ball in the nearer and nearer future. If you are predicting what happens in two years, that doesn’t really matter. You need to know what’s happening tomorrow.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Kapow Technologies.

November 5th, 2009

Role of governance plumbed in Nov. 10 webinar on managing hybrid and cloud computing types

Posted by Dana Gardner @ 10:27 am

Categories: Agile Development, Amazon, Cloud computing, Developer Tools, Google, IT Management, IT Service Management, ITIL, Microsoft, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, Virtualization, Web Services, Windows, datacenters, governance, mainframe, management

Tags: Governance, Webinar, Service-Oriented Architecture (SOA), Cloud Computing, Virtualization, Web Services, Enterprise Software, Software, Hardware, Dana Gardner

I‘ll be joining John Favazza, vice president of research and development at WebLayers, on Nov. 10 for a webinar on the critical role of governance in managing hybrid cloud computing environments.

The free, live webinar begins at 2 p.m. EDT. Register at https://www2.gotomeeting.com/register/695643130. [Disclosure: WebLayers is a sponsor of BriefingsDirect podcasts.]

Titled “How Governance Gets You More Mileage from Your Hybrid Computing Environment,” the webinar targets enterprise IT managers, architects and developers interested in governance for infrastructures that include hybrids of cloud computing, software as a service (saaS) and service-oriented architectures (SOA). There will be plenty of opportunity to ask questions and join the discussion.

Organizations are looking for more consistency across IT-enabled enterprise activities, and are finding competitive differentiation in being able to best manage their processes more effectively. That benefit, however, requires the ability to govern across different types of systems and infrastructure and applications delivery models. Enforcing policies, and implementing comprehensive governance, acts to enhance business modeling, additional services orientation, process refinement, and general business innovation.

Increasingly, governance of hybrid computing environments establishes the ground rules under which business activities and processes — supported by multiple and increasingly diverse infrastructure models — operate.

Developing and maintaining governance also fosters collaboration between architects, those building processes and solutions for companies, and those operating the infrastructure — be it supported within the enterprise or outside. It also sets up multi-party business processes, across company boundaries, with coordinated partners.

Cambridge, Mass.-based WebLayers provides a design-time governance platform that helps centralize policy management across multiple IT domains — from SOA through mainframe and cloud implementations. Such governance clearly works to reduce the costs of managing and scaling such environments, individually and in combination.

In the webinar we’ll look at how structured policies, including extensions across industry standards, speeds governance implementations and enforcement — from design-time through ongoing deployment and growth.

So join me and Favazza and me at 2 p.m. ET on Nov. 10 by registering at https://www2.gotomeeting.com/register/695643130.

November 3rd, 2009

Survey: Virtualization and physical infrastructures need to be managed in tandem

Posted by Dana Gardner @ 12:56 pm

Categories: Agile Development, Amazon, Cloud computing, Enterprise Java, Google, HP, IBM, IT Management, IT Service Management, Microsoft, Oracle, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Testing Tools, VMware, Virtualization, Web Services, governance, management

Tags: Survey, Infrastructure, Noteworthy, Cloud Computing, Marketing Research, Storage Management, Virtualization, Utility Computing, Marketing, Storage

If your company uses test and development infrastructures as a proving ground for shared services, virtualization and private cloud environments, you’re not alone. More companies are moving in that direction, according to a Taneja Group survey.

Yet underlying the use of the newer infrastructure approaches lies a budding challenge. The recent Taneja Group survey of senior IT managers working on test/dev infrastructures at North American firms found that 72 percent of respondents said virtualization on its own doesn’t address their most important test/dev infrastructure challenges. Some 55 percent rate managing both virtual and physical resources as having a high or medium impact on their success. The market is clearly looking for ways to bridge this gap.

Sharing physical and virtual infrastructures

Despite the confusion in the market about the economics of the various flavors of cloud computing, Dave Bartoletti, a senior analyst and consultant at Taneja Group, says one thing is clear: Enterprises are comfortable with, and actively sharing, both physical and virtual infrastructures internally.

“This survey reaffirms that shared infrastructure is common in test/dev environments and also reveals it’s increasingly being deployed for production workloads,” Bartoletti says. “Virtualization is seen as a key enabling technology. But on its own it does not address the most important operational and management challenges in a shared infrastructure.”

Half the survey respondents are funding projects starts in 2009. Another 66 percent of respondents will have funded a project started by the end of 2010.

Noteworthy is the fact that 92 percent of test/dev operations are using shared infrastructures, and companies are making significant investments in infrastructure-sharing initiatives to address the operational and budgetary challenges. Half the survey respondents are funding projects in 2009. Another 66 percent of respondents will have funded a project started by the end of 2010.

The survey reveals most firms are turning to private cloud infrastructures to support test/dev projects, and that shared infrastructures are beginning to bridge the gap between pre-production and production silos. A full 30 percent are sharing resource pools between both test/dev and production applications. This indicates a rising comfort level with sharing infrastructure within IT departments.

Virtualization’s cost and control issues

Although 89 percent of respondents use virtualization for test/dev, more than half have virtualized less than 25 percent of their servers. That’s because virtualization adds several layers of control and cost issues that need to be addressed by sharing, process, workflow and other management capabilities in order to fully maximize and integrate both virtual and physical infrastructures.

“Test/Dev environments are one of the most logical places for organizations to begin implementing private clouds and prove the benefits of a more elastic, self service, pay-per-use service delivery model,” says Martin Harris, director Product Management at Platform Computing. “We’ve certainly seen this trend among our own customers and have found that additional management tools enabling private clouds are required to effectively improve business service levels and address cost cutting initiatives.” [Disclosure: Platform Computing is a sponsor of BriefingsDirect podcasts.]

Despite the heavy internal investments, however, 82 percent of respondents are not using hosted environments outside their own firewalls. The top barriers to adoption: Lack of control and immature technology.

BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post.

November 3rd, 2009

You'll be far better off in a future without enterprise software

Posted by Dana Gardner @ 7:05 am

Categories: .NET, Agile Development, Amazon, Cloud computing, Enterprise Java, HP, Hardware Infrastructure, IBM, IT Management, IT Service Management, Microsoft, Open Source, Oracle, Progress Software, Red Hat, SAP, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, System Z, Virtualization, Web Services, datacenters, governance, mainframe, management

Tags: Enterprise Software, Software, Dana Gardner

This guest post comes courtesy of Ronald Schmelzer, senior analyst at ZapThink.

By Ronald Schmelzer

The conversation about the role and future of enterprise software is a continuous undercurrent in the service oriented architecture (SOA) conversation. Indeed, ZapThink’s been talking about the future of enterprise software in one way or another for years.

So, why bother bringing up this topic again, at this juncture? Has anything changed in the marketplace? Can we learn something new about where enterprise software is heading? The answer is decidedly “yes” to the latter two questions. And this might be the right time to seriously consider acting on the very things we’ve been talking about for a while.

The first major factor is significant consolidation in the marketplace for enterprise software. While a decade or so ago there were a few dozen large and established providers of different sorts of enterprise software packages, there are now just a handful of large providers, with a smattering more for industry-specific niches.

We can thank aggressive M&A activity combined with downward IT spending pressure for this reality. As a result of this consolidation, many large enterprise software packages (such as enterprise resource planning (ERP), customer relationship management (CRM), supply chain management (SCM) offerings) have been eliminated, are in the process of being phased out, or are getting merged (or “fused”) with other solutions.

Many companies rationalized the spending of millions of dollars on enterprise software applications because the costs could be amortized over a decade or more of usage, and they could claim that these enterprise software applications would be cheaper, in the long run, than building and managing their existing custom code. But, we’ve now had a long enough track record to realize that the result of mass consolidation, need for continuous spending, and inflexibility is causing many companies to reconsider that rationalization.

We can thank expensive, cumbersome, and tightly-coupled customization, integration, and development for this lack of innovation in enterprise software.

Furthermore, by virtue of their weight, significance in the enterprise environment, and astounding complexity, enterprise software solutions are much slower to adopt and adapt to new technologies that continuously change the face of IT.

We refer to this as the “enterprise digital divide.” You get one IT user experience when you are at home and use the Web, personal computing, and mobile devices and applications and a profoundly worse experience when you are at work. It’s as if the applications you use at work are a full decade behind the innovations that are now commonplace in the consumer environment. We can thank expensive, cumbersome, and tightly coupled customization, integration, and development for this lack of innovation in enterprise software.

In addition, no company can purchase and implement an enterprise software solution “out of the box.” Not only does a company need to spend significant money customizing and integrating their enterprise software solutions, but they often spend significant amounts of money on custom applications that tie into and depend on the software.

What might seem to be discrete enterprise software applications are really tangled masses of single-vendor functionality, tightly-coupled customizations and integrations, and custom code tied into this motley mess. In fact, when we ask people to describe their enterprise architecture (EA), they often point to the gnarly mess of enterprise software they purchased, customized, and maintain. That’s not EA. That’s an ugly baby only a mother could love.

Yet, companies constantly share with us their complete dependence on a handful of applications for their daily operation. Imagine what would happen at any large business if you were to shut down their single-vendor ERP, CRM, or SCM solutions. Business would grind to a halt.

While some would insist on the necessity of single-vendor, commercial enterprise software solutions as a result, we would instead assert how remarkably insane it is for companies to have such a single point of failure. Dependence on a single product, single vendor for the entirety of a company’s operations is absolutely ludicrous in an IT environment where there’s no technological reason to have such dependencies. The more you depend on one thing for your success, the less you are able to control your future. Innovation itself hangs in the balance when a company becomes so dependent on another company’s ability to innovate. And given the relentless pace of innovation, we see huge warning signs.

Services, clouds, and mashups: Why buy enterprise software?

In previous ZapFlashes, we talked about how the emergence of services at a range of disparate levels combined with evolutions in location- and platform-independent, on-demand, and variable provisioning enabled by clouds, and rich technologies to facilitate simple and rapid service composition will change the way companies conceive of, build, and manage applications.

Instead of an application as something that’s bought, customized, and integrated, the application itself is the instantaneous snapshot of how the various services are composed together to meet user needs. From this perspective, enterprise software is not what you buy, but what you do with what you have.

One outcome of this perspective on enterprise software is that companies can shift their spending from enterprise software licenses and maintenance (which eats up a significant chunk of IT budgets) to service development, consumption, and composition.

This is not just a philosophical difference. This is a real difference. While it is certainly true that services expose existing capabilities, and therefore you still need those existing capabilities when you build services, moving to SOA means that you are rewarded for exposing functionality you already have.

Whereas traditional enterprise software applications penalize legacy because of the inherent cost of integrating with it, moving to SOA inherently rewards legacy because you don’t need to build twice what you already have. In this vein, if you already have what you need because you bought it from a vendor, keep it – but don’t spend more money on that same functionality. Rather, spend money exposing and consuming it to meet new needs. This is the purview of good enterprise architecture, not good enterprise software.

When you ask these people to show you their enterprise software, they’ll simply point at their collection of Services, Cloud-based applications, and composition infrastructure.

The resultant combination of legacy service exposure, third-party service consumption, and the cloud (x-as-a-service) has motivated the thinking that if you don’t already have a single-vendor enterprise software suite, you probably don’t need one.

We’ve had first-hand experience with new companies that have started and grown operations to multiple millions of dollars without buying a penny of enterprise software. Likewise, we’ve seen billion-dollar companies dump existing enterprise software investments or start divisions and operations in new countries without extending their existing enterprise software licenses. When you ask these people to show you their enterprise software, they’ll simply point at their collection of services, cloud-based applications, and composition infrastructure.

Some might insist that cloud-based applications and so-called software-as-a-service (SaaS) applications are simply monolithic enterprise software applications deployed using someone else’s infrastructure. While that might have been the case for the application service provider (ASP) and SaaS applications of the past, that is not the case anymore. Whole ecosystems of loosely-coupled service offerings have evolved in the past decade to value-add these environments, which look more like catalogs of service capabilities and less like monolithic applications.

Want to build a website and capture lead data? No problem — just get the right service from Salesforce.com or your provider of choice and compose it using web services or REST or your standards-based approach of choice. And you didn’t incur thousands or millions of dollars to do that.

Open source vs. commercial vs. build your own

Another trend pointing to the stalling of enterprise software growth is the emergence of open source alternatives. Companies now are flocking to solutions such as WebERP, SugarCRM Community Edition, and other no-license and no-maintenance fee solutions that provide 80% of the required functionality of commercial suites.

While some might point at the cost of support for these offerings, we point out the factor of difference between support and license/maintenance costs. At the very least, you know what you’re paying for. It’s hard to justify spending millions of dollars in license fees when you’re using 10% or less of a product’s capabilities.

Enhancing this open source value proposition is that others are building capabilities on top of those solutions and giving those solutions away as well. The very nature of open source enables creation of capabilities that further value-adds a product suite. At some point, a given open source solution reaches a tipping point where the volume of enhancements far outweighs what any commercial vendor can offer. Simply put, when a community supports an open source effort, the result can out-innovate any commercial solution.

There are now a lot of pieces and parts available that are free, cheap, or low cost that companies can assemble into not only workable, but scalable offerings that can compete with many commercial offerings.

Beyond open source, commercial, and SaaS-cum-cloud offerings, companies have a credible choice in building their own enterprise software application. There are now a lot of pieces and parts available that are free, cheap, or low cost that companies can assemble into not only workable, but scalable offerings that can compete with many commercial offerings. In much the same way that companies leveraged Microsoft’s Visual Basic to build applications using the thousands of free or cheap widgets and controls built by the legions of developers, so too are we seeing a movement to free or cheap Service widgets that can enable remarkably complex and robust applications.

The future of commercial enterprise software applications

It is not clear where commercial enterprise software applications go from here. Surely, we don’t see companies tearing out their entrenched solutions any time soon, but likewise, we don’t see much reason for expansion in enterprise software sales either.

In some ways, enterprise software has become every bit the legacy they sought to replace in mainframe applications that still exist in abundance in the enterprise. Smart enterprise software vendors realize that they have to get out of the application business altogether and focus on selling composable service widgets. These firms, however, don’t want to innovate their way out of business. As such, they don’t want to just provide the trains to get you from place to place, but they want to own the tracks as well.

The question is: Is the cost of the proprietary runtime infrastructure you are getting with those widgets worth the cost?

In many ways, this idea of enterprise software-as-a-platform is really just a shell game. Instead of spending millions on a specific application, you’re instead spending millions on an infrastructure that comes with some pre-configured widgets. The question is: Is the cost of the proprietary runtime infrastructure you are getting with those widgets worth the cost? Have you lost some measure of loose coupling in exchange for a “single throat to choke?”

Much of the enterprise software market is heading in direct collision course with middleware vendors who never wanted to enter the application market. As enterprise software vendors start seeing their runtime platform as the defensible position, they will start conflicting with EA strategies that seek to remove their single-vendor dependence.

We see this as the area of greatest tension in the next few years. Do you want to be in control of your infrastructure and have choice, or do you want to resign your infrastructure to the control of a single vendor, who might be one merger or stumble away from non-existence or irrelevance?

The ZapThink take

We hope to use this ZapFlash to call out the ridiculousness of multi-million dollar “applications” that cost millions more to customize to do a fraction of what you need. In an era of continued financial pressure, the last thing companies should do is invest more in technology conceived of in the 1970s, matured in the 1990s, and incrementally made worse since then.

The reliance on single-vendor mammoth enterprise software packages is not helping, but rather hurting the movement to loosely coupled, agile, composition-centric heterogeneous SOA. Now is the time for companies to pull up the stakes and reconsider their huge enterprise software investments in favor of the sort of real enterprise architecture that cares little about buying things en masse and customizing those solutions — but instead to building, composing, and reusing what you need iteratively to respond to continuous change.

As if to prove a point, SAP stock recently slid almost 10% on missed earnings. Some may blame the overall state of the economy, but we point to the writing on the wall: All the enterprise software that could be sold has been sold, and the reasons for buying or implementing new licenses are few and far between. Invest in enterprise architecture over enterprise software, services over customizations, and clouds over costly and unpredictable infrastructure — and you’ll be better off.

This guest post comes courtesy of Ronald Schmelzer, senior analyst at ZapThink.


SPECIAL PARTNER OFFER

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.


October 30th, 2009

Internet performance management makes data center consolidation possible

Posted by Dana Gardner @ 1:56 pm

Categories: .NET, Akamai, Amazon, Cisco, Cloud computing, Home, Internet, Podcasts, SaaS, Software Development, Software Infrastructure, VMware, Virtualization, Web Services, datacenters, governance, management

Tags: Data Center, Performance, Performance Management, Data Center Consolidation, Akamai Technologies Inc., Data Centers, Storage, Internet, Hardware, Data Management

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Akamai Technologies.

Data-center consolidation and modernization of IT systems helps enterprises reduce cost, cut labor, slash energy use, and become more agile.

Infrastructure advancements, standardization, performance density, and network services efficiencies are all allowing for bigger and fewer data centers and strategically architected and located facilities that can efficiently carry more of the total IT requirements load.

But to gain the benefits of these large and strategic infrastructure undertakings, the impact on the network beyond the firewall has to be considered. User expectations for performance and IT requirements for reliability need to be maintained, and even improved.

Fewer data centers means longer distances between servers and users. Network services and Internet performance management therefore need to be brought considered to produce the desired effect of topnotch applications and data delivery to enterprises, consumers, partners, and employees at far lower cost.

Here to help us better understand how to get the best of all worlds — that is, high performance and lower total cost from data center consolidation — we’re joined by James Staten, Principal Analyst at Forrester Research; Andy Rubinson, Senior Product Marketing Manager at Akamai Technologies, and Tom Winston, Vice President of Global Technical Operations at Phase Forward, a provider of integrated data management solutions for clinical trials and drug safety. The panel is moderated by me, BriefingsDirect’s Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Staten: Oftentimes, the biggest reason to do [consolidation] is because you have sprawl in the data center. You’re running out of power, you’re running out of the ability to cool any more equipment, and you are running out of the ability to add new servers, as your business demands them.

If there are new applications the business wants to roll out, and you can’t bring them to market, that’s a significant problem. This is something the organizations have been facing for quite some time.

As a result, if they can start consolidating, they can start moving some of these workloads onto fewer systems. This allows them to reduce the amount of equipment they have to manage and the number of software licenses they have to maintain and lower their support costs. In the data center overall, they can lower their energy costs, while reducing some of the cooling required.

… Most applications actually end up consuming on average only 15-20 percent of the server. If that’s the case, you’ve got an awful lot of headroom to put other applications on there.

We were isolating applications on their own physical systems, so that they would be protected from any faults or problems with other applications that might be on the same system and take them down. Virtualization is the primary isolating technology that allows us to do that.

… More and more applications are being broken down into modules, and, much like the web services and web applications that we see today, they’re broken into tiers. Individual logic runs on its own engine, and all of that can be spread across some more monetized, consistent infrastructure. We are learning these lessons from the dot-coms of the world and now the cloud-computing providers of the world, and applying them to the enterprise.

… On average, across all the enterprises we have spoken to, you can realistically expect to see about a 20 percent cost reduction from doing this. But, as you said, if you’ve got 5,000 servers, and they’re all running at 5 percent utilization, there are big gains to be had.

Rubinson: I focus mainly on delivery over the Internet. There are definitely some challenges, if you’re talking about using the Internet with your data center infrastructure — things like performance latency, availability challenges from cable cuts, and things of that nature, as well as security threats on the Internet.

It’s thinking about how can you do this, how can you deliver to a global user base with your data center, without having to necessarily build out data centers internationally, and to be able to do that from a consolidated standpoint.

… From the cost perspective, we’re able to eliminate unnecessary hardware. We’re able to take some of that load off of the servers, and do the work in the cloud, which also helps reduce them.

… In terms of responsiveness, by using the Internet, you can deploy a lot more quickly. It allows us to give that same type of performance, availability, and security that you would get from having a private WAN, but doing it over the much less expensive Internet.

This is really important, as we have seen more and more users that are going outside of the corporate [networks]. People are connecting to suppliers, to partners, to customers, and to all sorts of things now.

… By optimizing the cloud, we’re able to speed the delivery of information from the origin as well. That’s where it’s benefiting folks like Tom, where he is able to not only cache information, but the information that is dynamic, that needs to get back from the data center, goes more quickly.

Winston: When I joined [Phase Forward], it had two different data centers — one on the East Coast and one on the West Coast. We were facing the challenge of potentially having to expand into a European data center, and even potentially a Pacific Rim data center.

By continuing to expand our virtualization efforts, as well as to leverage some of the technologies that Andy just mentioned … Internet acceleration via some of the Akamai technologies, we were able to forgo that data center expansion. In fact, we were able to consolidate our data center to one East Coast data center, which is now our primary hosting center for all of our applications.

So it had a very significant impact for us by being able to leverage both that WAN acceleration, as well as virtualization, within our own four walls of the data center.

We run electronic data capture (EDC) software, and pharmacovigilance software for the largest pharmaceutical and clinical device makers in the world. They are truly global organizations in nature. So, we have users throughout the world, with more and more heavy population coming out of the Asia Pacific area.

… We have a very large, diverse user base that is accessing our applications 24×7x365, and, as a result, we have performance needs all the time for all of our users.

… Our primary application, our flagship application, is a product called InForm, which is the main EDC product that our customers use across the Internet. It’s accelerated using Akamai technology, and almost 100 percent of our content is dynamic. It has worked extremely well.

Staten: … Users are all over the place. Whether they are an internal employee, a customer, or a business partner, they need to get access to those applications, and they have a performance expectation that’s been set by the Internet. They expect whatever applications they are interacting with will have that sort of local feel.

That’s what you have to be careful about in your planning of consolidation. You can consolidate branch offices. You can consolidate down to fewer data centers. In doing so, you gain a lot of operational efficiencies, but you can potentially sacrifice performance.

You have to take the lessons that have been learned by the people who set the performance bar, the providers of Internet-based services, and ask, “How can I optimize the WAN? How can I push out content? How can I leverage solutions and networks that have this kind of intelligence to allow me to deliver that same performance level?” That’s really the key thing that you have to keep in mind. Consolidation is great, but it can’t be at the sacrifice of the user experience.

… The right location [for data centers] has to be optimized for a variety of factors. It has to be optimized for where the appropriate skill sets are. It has to be optimized for the geographic constraints that you may be under.

We’re able to take some of that load off of the servers, and do the work in the cloud, which also helps reduce them.

You may be doing business in a country in which all of the citizen information of the people who live in that country must reside in that country. If that’s the case, you don’t necessarily have to own a data center there, but you absolutely have to have a presence there.

Winston: … We had users in China who, due to the amount of traffic that had to traverse the globe, were not happy with the performance of the application. Specifically, we brought in Akamai to start with a very targeted group of users and to be able to accelerate for them the application in that region.

It literally cut the problem right out. It solved it almost immediately. At that point, we then began to spread the rest of that application acceleration product across the rest of our domains, and to continue to use that throughout the product set.

Rubinson: … We recently commissioned a study with Forrester, looking at what is that tolerance threshold [for a page to load]. In the past it had been that people had tolerance for about four seconds. As of this latest study, it’s down to two seconds. That’s for business to consumer (B2C) users. What we have seen is that the business-to-business (B2B) users are even more intolerant of waiting for things.

It really has gotten to a point where you need that immediate delivery in order to drive the usage of the tools that are out there.

… Just putting yourself in the cloud doesn’t mean that you’re not going to have the same type of latency issues, delivering over the Internet. It’s the same thing with availability in trying to reach folks who are far away from that hosted data center. So, the cloud isn’t necessarily the answer. It’s not a pill that you can take to fix that issue.

… For Akamai, it’s really about how we’re able to accelerate. How we are able to optimize the routing and the other protocols on the Internet to make that get from wherever it’s hosted to a global set of end users.

We don’t care about where they are. They don’t have to be on the corporate, private WANs. It’s really about that global reach and giving the levels of performance to actually provide an SLA. Tell me who else out there provides an SLA for delivery over the Internet? Akamai does.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Akamai Technologies.

October 26th, 2009

Linthicum's latest book: How SOA and cloud intersect for enterprise productivity benefits

Posted by Dana Gardner @ 12:30 pm

Categories: Agile Development, Amazon, Cloud computing, Google, HP, IBM, IT Management, IT Service Management, Microsoft, Podcasts, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, Virtualization, Web Services, datacenters, governance, management

Tags: Benefit, SOA, Cloud, Linthicum, Dave Linthicum, Service-Oriented Architecture (SOA), Web Services, Cloud Computing, Middleware, Virtualization

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 45. This periodic discussion and dissection of IT infrastructure related news and events with industry analysts and guests, looks at a new book on cloud computing, a step-by-step guide on figuring out the right path to combined cloud and SOA benefits.

Dave Linthicum’s new book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide, has just arrived and digs into the conflation of SOA and cloud computing. Our discussion with Linthicum on his findings is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Linthicum: SOA is the way to do cloud. I saw early on that SOA, if you get beyond the hype that’s been around for the last two years, is really an architectural pattern that predates the SOA buzzword, or the SOA TLA.

It’s really about breaking down your architecture into a primitive state of several components, including services and data and processes. Then, it’s figuring out how to assemble those in such a way that you can not only solve your existing problems, but use those components to resolve problems, as your business changes over time or your mission changes or expands.

Cloud computing is a nice enhancement to that. Cloud doesn’t replace SOA, as some people say. Cloud computing is basically architectural options or ways in which you can host your services, in this case, in the cloud.

As we go through reinventing your architecture around the concept of SOA, we can figure out which components, services, processes, or data are good candidates for cloud computing, and we can look at the performance, security and governance aspects of it.

Architectural advantages

We find that some of our services can exist out on the platform in the cloud, which provides us with some additional architectural advantages such as self-provisioning, the ability to get on the cloud very quickly in a very short time without buying hardware and software or expanding our data centers, and the ability to rapidly expand as we need to expand basically on demand.

If we need to go from 10 users to 1,000 users, we can do so in a matter of weeks, not having to buy data-center space, waves and waves of servers, software, hardware licenses, and all those sorts of things. Cloud computing provides you with some flexibility, but it doesn’t get away from the core needs to architecture. So, really the book is about how to use SOA in the context of cloud computing, and that’s the message I’m really trying to get across.

… As we move toward cloud computing, there are more economical and cost-effective architectural options. There is also the ability to play around with SOA in the cloud, which I think is driving a lot of the SOA. In fact, I find that a lot of people build their first initial SOA as cloud-delivered systems, be it Amazon, IBM, Azure from Microsoft, and some of the other platforms that are out there.

Then, once they figure out the benefits of that, they start putting pieces of it on premise, as it makes sense, and put pieces of it on the cloud. It has the tendency to drive prototyping on the cheap and to leverage architecture and play around with different technologies without the investment we had to do in the past.

… We’ve got to stop the insanity. We’ve got control IT spending. We’ve got to be much more effective and efficient with the way in which we spend and leverage IT resources. Cloud computing is only a mechanism, it’s not a savior for doing that. We need to start marching in new directions and being aggressively innovative around the efficiency, the expandability, and ultimately the agility of IT.

… When you’re doing SOA and considering SOA within your enterprise or agency, you should always consider cloud as an architectural option. In other words, we have servers we’re looking to deploy in middleware, we’re looking to leverage in databases we’re looking to leverage in terms of SOA. It’s governance systems, security systems, and identity management.

Cloud computing is really another set of things that you need to consider in the context of SOA, and you need to start playing around with the stuff now, because it’s so cheap. There’s no reason that anybody who’s working on an SOA shouldn’t be playing around with cloud, given the amount of investment that’s needed. It’s almost nothing, especially with some of the initial forays, some of the prototypes, and some of the pilot projects that need to be done around cloud.

Software as a service (SaaS) is probably the easiest way to get into the cloud. It also has the most potential to save you the greatest amount of money. Instead of buying a million-dollar, or a two-million-dollar customer reliationship management (CRM) system, you can leverage Salesforce.com for $50-60 a month.

After that, I would progress into infrastructures as a service (IaaS), and that’s basically data center on demand. So, it’s databases, application servers, WebSphere, and all those sorts of things that you are able to leverage from the data center, but, instead of a data center, you leverage it from the cloud.

Guys like Amazon obviously are in that game. Microsoft, or the Azure platform, are in that game. Any number of players out there are going to be able to provide you with core infrastructure or primitive infrastructure. In other words, it’s just available to you over the ‘Net with some of kind of a metering system. I would start playing around with that technology after you get through with SaaS.

. . . Instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.

Then, I would take a look at the platform-as-a-service (PaaS) technology, if you are doing any kind of application development. That’s very cool stuff. Those are guys like Force, Google App Engine, and Bungee Labs. They provide you with a complete application development and deployment platform as a service. Then, I would progress into the more detailed stuff — database, storage, and some of the other more sophisticated services on top of the primitive services that we just mentioned.

… PaaS with that Google App Engine is driving a lot of innovation right now. People are building applications out there, because they don’t have to bother existing IT to get servers and databases brought online, and that will spur innovation.

So, today, we could figure out we want to go off and build this great application and do this great thing to automate a business and, instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.

Huge potential

Then, we can start building, deploying, defining the database, do the testing, get it up and running, and have it immediately. It’s web based and accessible to millions of users who are able to leverage the application in a scalable way. It’s an amazing kind of infrastructure when you think about it. The potential is there to build huge, innovative things with very few resources.

… Ten years ago, it was very difficult to do a start up. You’d have a million dollars in investment funds just to get your infrastructure up and running. Now, startups can basically operate with a minimal amount of resources, typically a laptop, pointing at any number of cloud resources.

They can build their applications out there. They can build their intellectual capital. They can build their software. They can deploy it. They can test it. Then, they can provision the customers out there and meter their customers. So, it’s a great time to be in this business.

… There needs to be a lot of education about the opportunities and the advantages of using cloud computing, as well as what the limitations are and what things we have to watch out for. Not all applications and all pieces of data are going to be right for the cloud. However, we need to educate people in terms of what the opportunities are.

The fact of the matter is that it’s not going to be a dysfunctional and risky thing to move pieces of our architecture out into cloud computing. Get them around the pilot. Get them to go out there and try it. Get them to basically experiment with the technology. Figure out what the capabilities are, and that will ultimately change the culture.

… We’re going to get to a point where the data is going to be a ubiquitous thing. It doesn’t really matter where it resides and where we can access it, as long as we access it from a particular model. It’s not going to make any difference to the users either. I just blogged about that in InfoWorld.

In fact, we’re getting into this notion of what I call the “invisible cloud.” In other words, we’re not doing application as a service or SaaS, where people get new interfaces that are web-driven. We’re putting pieces of the back-end architectural components — processes, services, and, in this case, data — out on the platform of the cloud. It really doesn’t matter to them where that data resides, as long as they can get at it when they need it.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint’s ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

October 21st, 2009

Here's why Apple is doing so well -- it's the top half, stupid

Posted by Dana Gardner @ 6:09 am

Categories: Apple, Cloud computing, Enterprise 2.0, HP, Hardware Infrastructure, Internet, Microsoft, Mobile, Silicon Valley, Software Development, Software Infrastructure, Vista, Web Services, Windows, iPhone, management

Tags: Innovation, Knowledge, Information Technology, Apple Inc., Thomas Friedman, Entrepreneurship, Strategy, Productivity, Leadership, Management

I’ve been ruminating the past few days on why Apple is doing so well with it’s pricey high-end products and services during a recession. The answer came as I was reading today’s New York Times column by Thomas Friedman, whom I deeply admire and read anything and everything he puts out.

Friedman points out that the winners in today’s fast-shifting U.S. job market are the ones demonstrating “entrepreneurship, innovation and creativity.” He says, “They are the new untouchables,” in contrast to other still highly educated but less creative types.

Friedman cites Harvard University labor expert Lawrence Katz, who explains in the column that the now disadvantaged are “those engineers and programmers working on more routine tasks and not actively engaged in developing new ideas or recombining existing technologies or thinking about what new customers want. … They’ve been much more exposed to global competitors that make them easily substitutable.”

They are also more likely to be using personal computers with nine-year-old operating systems, with little choice but to take what their companies provide in terms of personal productivity IT. They are the 90 percent for whom good enough IT has made them as good as anyone anywhere.

In contrast, it’s the “top half” of the labor pool, and more specifically the apparent 10 percent that are “entrepreneurship, innovation and creativity”-focused among them, that know to succeed and win they need the very best computer and associated services, even if it costs $500 more. Nowadays there’s no better way to gain an advantage in business and life than to have the best technology.

The people who are succeeding are buying Macs, iPhones, iPod Touches and Apple’s services and applications. A flight to quality is usually spurred by disruption and uncertainty. It’s not about brand religion or pretty graphics. It’s about survival and success when the going gets tough. It works for me, it has to.

A chef doesn’t buy the cheapest knifes. A painter doesn’t buy the cheapest brushes. A carpenter doesn’t buy the cheapest hammer. And all the winners in the economy today — those that have a say in what they use to do all the digital things so critical now to almost any knowledge- and services-based job — need the best tools. And they will upgrade those tools just as fast as they can (hence the rapid adoption of Apple’s Snow Leopard OS X upgrade in recent months.)

So for all those millions of newly laid off workers who know that “entrepreneurship, innovation and creativity” is their only ticket to a new, fresh start — those that no longer have an IT department to tell them what to do (at lowest cost) — they seem to be making a new move to a Mac. I expect they won’t soon go back, once they taste the fruits of heightened knowledge productivity.

Because when failure is not an option, you have to have the best tools, especially when the going gets tough. The sad part is that Apple does so well when so many are not.

October 19th, 2009

Speaking of SOA: Are services nouns or verbs?

Posted by Dana Gardner @ 11:09 am

Categories: .NET, Agile Development, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, IT Service Management, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Web Services, governance, management

Tags: Operation, ZapThink LLC, Policy, SOA, Simple Object Access Protocol, Object-oriented, Service-Oriented Architecture (SOA), Web Services, SOAP, Ooa/Ood/Oop

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

By Jason Bloomberg

ZapThink revels in stirring up controversy almost as much as we enjoy clarifying subtle concepts that give architects that rare “aha!” moment as they finally discern the solution to a particularly knotty design problem. Last month’s “process isomorphism” ZapFlash, therefore, gave us a particular thrill, because we received kudos from enterprise architects for streamlining the connections between Business Process Management (BPM) and Service-Oriented Architecture (SOA), while at the same time, several industry pundits demurred, disagreeing with our premise that services should correspond one-to-one with tasks or subtasks in a process.

Maybe we got it wrong, and inadvertently mislead our following of architects? Or perhaps the pundits were off base, and somehow ZapThink saw clearly a best practice that remained obscure to other experts in the field?

Upon further consideration, the true answer lies somewhere in between these extremes. Now, we’re not reconsidering the conclusions of the process isomorphism ZapFlash. Rather, further explanation and clarification is warranted.

As with any best practice, process isomorphism doesn’t apply in every situation, and not every service should correspond to a process task or subtask. That being said, there is also a good chance that some of our esteemed fellow pundits might not be opining from a truly service-oriented perspective, as many of their comments hint at an object-oriented (OO) bias that may be too limiting in the SOA context.

In fact, understanding which services the process isomorphism pattern applies to, and how other services support such services goes to the heart of how to think about services from a SOA perspective.

The object-oriented context for services

In the early days of web services, as various standards committee members tried to hash out how core standards should support the vision of SOA, the SOAP standard for message transport was an acronym for the “Simple Object Access Protocol.” The reasoning at the time was that services were interfaces to objects, and hence service operations should correspond to object methods, also known as remote procedures.

SOAP was nothing more than a simple, XML-based way of access those methods. Over time, however, people realized that taking this Remote Procedure Call (RPC) approach to service interfaces is too limiting: It leads to tightly coupled, synchronous interactions that constrain the benefits such services could offer. Instead, the industry settled on document style as being the preferred interface style, which expects requests and responses to conform to schemas that are included in the service contracts by reference, where the underlying service logic is responsible for validating interactions against the relevant schemas.

Document style interfaces provide greater loose coupling than their RPC-style cousins because many changes to a service need not adversely impact existing service consumers, and furthermore, document style interfaces facilitate asynchronous interactions where a request need not correlate immediately with a response. In fact, the W3C eventually dropped the “Simple Object Access Protocol” definition of SOAP altogether, and now SOAP is just SOAP, instead of being an abbreviation of anything.

The answer is straightforward: If a service has no operations, then what it’s supposed to do is understood from the context of the service itself.

However, document style interfaces still allow for operations, only now they’re optional rather than mandatory as is the case with RPC-style interfaces. The fact that operations are optional is a never-ending sense of confusion for students in our Licensed ZapThink Architect course, perhaps because of the object-oriented pattern of thinking many of today’s techies follow, often without realizing it.

How would you ever know what a service is supposed to do, the reasoning goes, if you don’t call an operation on that service? The answer is straightforward: if a service has no operations, then what it’s supposed to do is understood from the context of the service itself. For example, an insurance company may want a service that simply approves a pending insurance policy. If we have an approvePolicy Service, the consumer can simply request that service with the policy number of the policy it wants to approve.

Nouns vs. Verbs

The insurance policy example brings up a fundamental question. Which is the service, the insurance policy entity or the approve policy task? In other words, should services be nouns or verbs? It’s possible to design services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

If you look at the question of whether services should be nouns or verbs from the OO perspective, then services are little more than interfaces to objects, and hence it’s best to think of services as nouns and their operations as the verbs. For example, following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudocode illustrates:

myPolicy = new Policy (); successOrFailure = myPolicy.approve ();

The first statement above instantiates a particular policy, while the second one approves it, and returns either success or failure.

Now, it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because services are fundamentally stateless, you don’t instantiate them. Here, then, is pseudocode that represents how an Entity Service would tackle the same functionality:

request to create new policy, specifying create policy operation –> Policy Service –> response with policy number 12345

request to approve policy 12345, specifying approve policy operation –> Policy Service –> response with success or failure

Note that we’re representing service interactions as input and output messages that contain documents, where in this case, the input documents specify operations. In this example, there is no object in the OO sense representing policy 12345 and maintaining the state information that indicates whether or not that particular policy is approved or not.

Instead, the underlying service implementation maintains the state information. There is only the one Policy Service, and it accepts requests in the form of XML documents and returns responses, also in the form of XML documents. If a request calls the create policy operation, then the Policy Service knows to create the policy, while a request that specifies the approve policy operation follows the same pattern.

Note that the fact that the Policy Service has a document style interface gives us two advantages: First, we can make certain changes to the service like adding new operations without adversely impacting existing consumers, and second, its stateless nature enables asynchronous interactions, where instead of returning success or failure of the approve request, perhaps, the service returns a simple acknowledgment of the request (or perhaps no response at all), and then notifies the consumer at some point in the future that the policy has been approved, either through a one-way notification event or possibly as a response to a further query.

Task services as verbs

While there is a significant role for Entity Services in SOA, it is important to break free from OO-centric thinking and consider other types of services as well that serve other purposes. In fact, there is another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudocode for this situation:

request to create new policy –> createNewPolicy Service –> response with policy number 12345

request to approve policy 12345 — > approvePolicy Service –> response with success or failure

In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies? If you read the process isomorphism ZapFlash, the benefits of delivering capabilities as Task Services is clear. If you design each Task Service to represent tasks or subtasks in business processes, then it’s possible to build a service-oriented business application (SOBA) that is isomorphic to the process it implements.

Combining entity and task services

A casual reading of the process isomorphism ZapFlash might lead you to think we were suggesting that all services should be Task Services. However, in spite of the fact that architects with OO backgrounds often rely too heavily on Entity Services, such services do play a critical role in most SOA implementations.

Remember that in the enterprise context, services expose existing, legacy capabilities and data that are typically scattered across different applications and data stores, limiting the enterprise’s agility and leading to high integration maintenance costs, poor data quality, reduced customer value, and other ills all too familiar to anybody working within a large organization’s IT department. SOA provides best practices for addressing such issues by abstracting such legacy capabilities in order to support flexible business processes.

Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other, as the figure below illustrates:

Process, task, and entity service layers

In the figure above, the bottom row contains Entity Services, which directly abstract underlying legacy capabilities. Above the Entity Services lie the Task Services, which may actually be abstractions of individual operations belonging to underlying Entity Services. The top layer contains Process Services, which are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.

The essential question for the architect is which capabilities to abstract in which service layer. Take for example the Address Change Task Service. Changing addresses is a common example of a particularly challenging task in many large organizations, because address information is typically maintained by different applications and data stores in a haphazard, inconsistent manner. To make matters worse, there may be addresses associated with customers, policies, or other business entities.

When architecting the Customer Entity Service, the core design principle is to pull together the various instances of customer-related information and functionality across the as-is legacy environment into a single, consolidated representation. Such a Service will likely have an update address operation, and the Customer Entity Service’s logic will encapsulate whatever individual queries and API calls are necessary to properly update customers’ addresses across all relevant systems.

The Address Change Task Service, then, abstracts the Customer Entity Service’s update address operation, as well as whatever other address change operations other Entity Services might have. The Service logic behind this Task Service understands, for example, that insured properties in polices have addresses and customers have addresses, and these addresses are related in a particular way, but are by no means equivalent.

The ZapThink take

As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the “right tool for the job” principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility.

In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep’s screen. In such instances the architect’s focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.

The big picture of the SOA architect’s challenge, of course, is delivering agility in the face of heterogeneity. On the one hand, the IT shop contains a patchwork of legacy resources, and on the other hand, the business requires increasingly agile processes. Understanding which capabilities belong in Entity Services and which belong in Task Services is a critical part of the best practice approach to SOA.

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.


SPECIAL PARTNER OFFER

SOA and EA Training, Certification and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.


Dana GardnerDana Gardner is principal analyst of Interarbor Solutions. For disclosures on Dana's industry affiliations, click here or to view his full profile click here.

Email Dana Gardner

Subscribe to BriefingsDirect via Email alerts or RSS.


Link to BriefingsDirect podcast. Subscribe to the podcast Feed. Subscribe with iTunes.


SponsoredWhite Papers, Webcasts, and Downloads

advertisement

Recent Entries

Most Popular Posts

advertisement

Archives

Favorite Links

ZDNet Blogs

White Papers, Webcasts, and Downloads

SmartPlanet

Click Here