Trends in Enterprise Software

What trends will emerge around the enterprise software space as we head into what looks to be shaping up as a daunting 2009?

Here's a look at three trends I thinks have been playing out, and will continue to do so even more noticeably in 2010 against the backdrop of the troubled economy.

1. Increased software consolidation among big vendors opens opportunities for smaller providers.
   
   
   Consolidation has been the trend in the BI space, with Business Objects, Cognos, Hyperion and Sun Microsystems being acquired respectively by SAP, IBM, and Oracle.
   
   When mergers occur in any part of the software sector, customers may take a breath to see what is going to happen to the products they use as they are brought into the acquirers fold. In the BI (Business Intelligence) world, the mergers of the last 18 months have created just that kind of "pause" effect, and it's opening up a real window of opportunity for open source companies and other more nimble start-ups that represent more modern alternatives.
   
   Large software companies have business models that require them to keep pushing the largest enterprise software deals, the largest sales, which means building bigger suites of software, so there's greater complexity and bigger price points which fuels additional opportunities for open source companies where the model is simple, integrated architectures. The cost, long deployment windows and complexity of existing BI technology means that it hasn't worked its way deep into the enterprise. Only 15 percent of users in the enterprise typically engage with BI software.
   
   Now when you have to get BI to those 85 percent of individuals not touched by it, you can get to them with lighter-weight, less complex solutions that solve the needs of the average worker in general.
   
   
2. Enterprises will be more interested in SOA and Web services-driven architectures that define newer software offerings.
   
   Large vendors of proprietary architectures will have a hard time adjusting and taking advantage of Web based 2.0 architectures and such. Smaller, lighter weight and open-source vendors will move more agilely.
   
   While larger software companies tout those architectures as well,what they are doing primarily is extending their architectures and exposing Web services to others for integration with other large enterprise systems. From that standpoint, Web services provide that connective mechanism so different enterprise software can interact. It actually can occur, and that's a good thing. But, that's fundamentally different from designing products from the ground up that take advantage of being built in a compartmentalized way to be far more flexible.
   
   
3. Consumerization of information.
   
   This is the least obvious and by far the most important and compelling over the long term.
   
   This will have a deep impact not just on IT and the way it implements and deploys and manages systems, but also on vendors who seek to provide solutions for that environment.
   
   Individuals in the workplace will want their enterprise systems to better reflect the way they are able to access and use information in their consumer lives. For vendors, that means rolling out software in a different way, and building experiences in the Web 2.0 vein using rich media software layers and the like. If you don't have the elegance of the best desktop applications built into a pure Web design, you will disappoint many of these workers who expect better experiences in online or Web applications.
   

Google Wave: Implications for the enterprise

Last week Google announced their forthcoming service known as Wave to widespread coverage in both the press and blogosphere.

Created by many of the same team members that developed the highly successful Google Maps, the preview of the service itself on Thursday was quite compelling, resulting in a rare standing ovation at a tech conference.

Its egalitarian and federation-friendly design is intended to create an entire open ecosystem for communication and collaboration that Google is not-so-modestly touting as the reinvention of digital interaction circa 2009.

Wave’s relevance to the enterprise might seem premature with so many of the early and current Web 2.0 applications (blogs, wikis, social networks, Twitter-style social messaging, mashups, etc.) still — often arduously — making their way into the workplace years after their inception. Though we seem to finally be hitting a tipping point with 2.0 tools at work, Wave itself seems credible enough to get on our watchlists, at least to understand the implications.

The real question is whether there are really such significant gaps in the current state of Web-based communication that we need something new like Wave.

Wave: A communication and collaboration mashup

Google Wave itself consists of a dynamic mix of conversation models and highly interactive document creation via the browser. Using simple, open Web technologies (Google makes much of the fact that most of Google Wave is a open set of formats and architectures that is jointly developed with the Web community) Wave combines many of the key features of e-mail, instant messaging, media sharing, and social networking into a seamless experience and data set that are eponymously known as waves. All of this is opened up to developers via the Google Wave API.

While waves are relatively self-contained and use their own types of servers and data formats, they are easy to embed elsewhere or to build extensions for, enabling virtually infinite options for distribution over the Web or within the firewall, as well as rapid integration with existing applications and data. In fact, a wave is almost a form of social glue between people and the information they care about. And as we’ll see, this has implications for the enterprise world, not only with SOA but also with social communication in general as well as Enterprise 2.0 specifically.

Wave in action

What Google has done with the Wave protocol is essentially create a new kind of social media format that is distinctively different from blogs, wikis, activity streams, RSS, or most familiar online communication models except possibly IM. Both blogs and wikis were created in the era of page-oriented Web applications and haven’t changed much since. In contrast, Google Wave is designed for real-time participation and editing of shared conversations and documents and is more akin to the simultaneous multiuser experience of Google Docs than with traditional blogs and wiki editing. Though Google is sometimes criticized for missing the social aspect of the Web, that is patently not the case with waves, which are fundamentally social in nature. Participants can be added in real-time, new conversations forked off (via private replies), social media sharing is assumed to be the norm, and connection with a user’s contextual server-side data is also a core feature including location, search, and more.

The result is stored in a persistent document known as a wave, access to which can be embedded anywhere that HTML can be embedded, whether that’s a Web page or an enterprise portal. Users can then discover and interact with the wave, joining the conversation, adding more information, etc. Google has also leveraged its investments in Google Gadgets and OpenSocial, two key technologies for spreading online services beyond the original boundaries of the sites they came from. All in all, Google Wave is a smart and well-constructed bundle of collaborative capabilities with many of the modern sensibilities we’ve come to expect in the Web 2.0 era including an acutely social nature, rapid interaction, and community-based technology.

Google Wave: An enterprise perspective

The hodge podge of 1990s era (and often older, in the case of e-mail) Internet communication methods were created in another time. Blogs, wikis, IM, and so on are all useful modes of communication but there are better ways and new requirements in today’s high social, interactive, and highly integrated times. That’s not to say that many companies haven’t tried to do this already, but virtually none of them have the ability to drive the modern development community or use their existing online market share to foster adoption in the end-user marketplace like Google does. In the end, barring a major misstep from Google, chances are good that organizations will have to deal with business data in the Wave Protocol format in the future.

Let’s take a closer look at what enterprises need to know about Google Wave:

• Google Wave largely complements and doesn’t replace existing communication and collaborative applications. Google Wave creates a healthy synthesis of existing application types by providing integration across existing channels. The early demos in fact showed how Twitter and existing social networks can play very well with Google Wave, enhancing the experience and allow broader participation. Google Wave won’t replace existing apps like e-mail, IM, blogs, or wikis, and will actually make the latter two stronger through embedding. Groupware and other simultaneously collaborative apps, however, are more at risk of displacement.
  
  
• Enterprise 2.0 is well supported by Google Wave. The general capabilities of FLATNESSES, my mnemonic for all the things that a capable Enterprise 2.0 platform should do, is well embodied in Google Wave. While blogs and wikis are the fundamental Enterprise 2.0 platforms, the basic capabilities of social interaction, emergence, and freeformedness are all there, though a wave presupposes a bit more structure and situated use than the more tabula rasa blog or wiki.
  
  
• New protocols, servers, data formats, and client applications are required to use wave. Unfortunately, Google Wave brings a lot of baggage with it, though it’s mostly straightforward. You will require new software, though not on the client since that all runs in a zero-footprint browser client. This means more integration code, management, and monitoring. The best news is that everything is well-documented, open, and any organization can participate in directing the wave community, so lock-in, while always possible, seems largely avoidable and Google takes great pains to draw us to that conclusion. Google is also pushing hard for alternative implementations of the client and server components, including on-premise implementations, with the former on display at their announcement.
  
  
• Waves are a natural integration point for many enterprise services including ECM, SOA, mashups, and more. By defining a strong protocol for continuous server-side processing of live conversations, Google has enabled an entire world where our IT systems are connected to the work we do every day. Literally while participants are busy typing and collaborating, a wave can be receiving support from back-end systems such as HRM, CRM, ERP, and so on to provide data, context, and other just-in-time support. Many businesses could benefit enormously from seamless business data integration such as customers, orders, and so on, never mind the deeper possibilities of contextual business processes leveraged directly in the collaborative activities of workers. I’ve written many times about the convergence of our IT systems and Web 2.0, and this seams one of the more natural environments for it that I’ve seen in a while.
  
  
• Embedding and extensions will enable widespread distribution and consumption of waves. Google brings ease-of-development for creating server-side extension as well as simple models for user-distribution of waves. While the first will enable easy integration with local data sources and will create a large aftermarket for useful extensions such as the aforementioned language translation capabilities, the second will virtually ensure that enterprises will have interaction with waves one way or another. Since the premise of the product is also one of the dominant activities in the business world (enabling teamwork) and combined with the increasing consumerization of the workplace, it’s highly likely that organizations will encounter waves in their work with external entities, especially with partners and clients. At the very least, organizations will need to understand how waves will make their organizations even more porous on the Internet, and have policies about participating in them, just like SaaS services, social networks, and other external applications. Security will also be an issue with waves though things like integration of Web 2.0 tools and ECM will actually be easier than ever before since a corporate archive robot could ensure every wave conversation is backed up in the formal ECM system.

Google has launched many communication services since its inception including Gmail, Gtalk, Blogger to name just three, yet none of these have had such obvious business utility or attempted to reinvent the collaborative process from the ground-up. While it’s always possible that Google Wave will never broadly take off (see Mary Jo Foley’s analysis of Wave here), I’m betting that it’s likely to be one of the most interesting offerings to businesses that the company has created yet. With the open positioning, early outreach to the world, and the clarity of purpose and design, Google Wave has a good shot at helping take Enterprise 2.0 to the next level in many organizations.

It's much too soon to really decide anything about Google Wave yet, but are you putting it on your watch list? Please put your comments in the comment box below. Thank you.

8 characteristics of successful SOA implementations

The SOA Consortium and CIO magazine recently announced the winners of the Service Oriented Architecture (SOA) Case Study Competition. All of the winners successfully delivered business or mission value using an SOA approach.

Mike Kavis, Chief Architect, Catalina Marketing, identified eight characteristics of successful SOA implementations. If your have been following SOA, you probably won't be surprised by his findings. But, for the rest of the world, it's a really great resource that nicely addresses a lot of the ongoing debate about how to approach SOA.

In fact, this list of eight characteristics really is a sort of Cliff Notes summarizing the past three years of discussion about implementing SOA.

SOA, has been a hotly debated notion, but I think most people now know SOA isn't just an IT initiative. You've got to talk to the business about SOA.

Now, that's not to say you should be selling SOA per se -- education is not the same thing as marketing. As Kavis points out, you don't even have to use the words "service-oriented architecture" if you don't want to -- although, personally, I think business leaders can handle it. But you do have to get across the message that you're doing something new that will deliver long-term benefits to the business:

"Instead the business needs to understand the key business drivers that are being addressed (quicker access to information, integration with customers and partners, eliminating wasteful business processes, etc.) on how IT has some 'new methods' for helping to deliver these drivers. The business doesn't necessarily need to know how IT will do it; they need to understand which of their problems SOA solves and what is required from the business to help IT solve them."

People tend to think of SOA as something that's good for IT, because it will cut development time or make IT efficient in other ways. Hey, if it's good for IT, it's good for business right? Uhm, sorry -- thanks for playing, but that's not enough. Kavis found that these SOA success stories all delivered more value to the business itself than IT:

"These may have been some side effects, but the value of the IT benefits are minuscule as compared to the business benefits which in some cases were in the billions of dollars over a given time period."

Just as SOA brings unique testing challenges, it changes your quality assurance requirements. ROI is difficult to achieve and takes time. Gartner contends that ROI is the wrong question for SOA, but some of these companies did achieve a substantial, measurable ROI. Others did not, at least in the short term. The point here is, this is not a technology investment -- it's an architectural shift. Promising an immediate ROI is just not practical with SOA.

Strong Executive Level Sponsorship and SOA Evangelist

Each project had strong sponsorship from high ranking individuals from the business and/or IT. This is critical for driving change throughout the organization and removing roadblocks. Without top-level support, many SOA initiatives never get the momentum, the resources and the drive required to allow IT to deliver the promise of SOA to the business. It was also noted that a strong SOA evangelist was highly critical for each of these award-winning case studies. In fact, research shows that in instances where SOA evangelists leave a company, the company has a risk of failing with future projects or regressing back to the previous methods of delivering software.

Educating the Business of the Value of SOA

Each one of the case studies provided an enormous amount of value to the business. In some cases, the return on investment was several billions of dollars over the course of a few years. In order to find these extraordinary opportunities and to build a business case around them, it is critical that the business becomes educated on the promise of SOA.The key to educating the business, however, is not talking to the business about the technology or even mentioning the term service-oriented architecture. Instead the business needs to understand the key business drivers that are being addressed (quicker access to information, integration with customers and partners, eliminating wasteful business processes, etc.) on how IT has some "new methods" for helping to deliver these drivers. The business doesn't necessarily need to know how IT will do it; they need to understand which of their problems SOA solves and what is required from the business to help IT solve them.

Established a Center of Excellence (CoE)

Every winning case study had some form of CoE established. It may have been called something else, such as a Configuration Control Board, but all had some formal body that was responsible for governing the SOA initiative. Some of these companies already had in place an established Enterprise Architecture complete with IT governance and simply needed to make adjustments for SOA. Others did not have a formal governance plan and had to create one with enough controls in place to deliver the desired business results. The level of control and the scope of each company's governance model were unique, but every successful project sited governance as a key success factor.

Start With Well-defined Business Processes and Scale Up

In each case, candidate services were identified after well-defined business processes were established. In some cases, the business processes were already in place; in others some business processing re-engineering was required prior to creating any services. In each case, the goal was to start with some subset of business processes as opposed to trying to do it all at once. Each case study had a well-defined scope and a vision of what the future state looked like.

Define Completeness of Work within Services

A lot of thought was put into which services were critical to the key business drivers. Business services provided a complete business function.

For example, let's say a core business service identified was a shopping cart function. The goal would be to build in all of the functionality required to make the shopping cart service functional, not just a checkout service. In this example, the complete business service would also need to accept payment, communicate with shipping partners, handle discounts, etc.

Most successful SOA implementations do not have a huge number of business services. This is where a lot of SOA projects run into trouble. They try to make everything into a service, whether it provides business value or not. There is a considerable amount of overhead and costs involved with building, governing, and maintaining services. Successful SOA implementations focus on a small number of core business services that provide real business value and don't waste precious time and money on services that don't have the payback.

Quality Assurance Is Key

As I mentioned in a previous article. SOA creates all sorts of new challenges for the QA department. Successful SOA implementations require that proper QA best practices, such as load testing of each service, is performed. Performance, security and governance testing should be a part of your overall testing plan to ensure that both the business and technical requirements are met.

ROI Is Difficult to Achieve Initially and Is Realized Over Time

SOA is not a technology; it is an architecture. Like any other architecture, value is earned over time as the architecture expands and matures. Some of these companies were on their second or third SOA project and were realizing substantial ROI. Others were in their first iteration and did not see immediate ROI but instead were laying down the foundation for future SOA projects to maximize their ROI.

Deliver Substantial Business Value

In all cases, these award winning case studies delivered substantial business value. None of these case studies were focused on fixing IT infrastructure or based solely on reducing development costs through reuse. These may have been some side effects, but the value of the IT benefits are minuscule as compared to the business benefits which in some cases were in the billions of dollars over a given time period.

So for all of the pundits out there who claim that you should never talk to the business about SOA or that SOA is an IT initiative not a business initiative-look at the huge ROIs of these projects and the business transformations that occurred and reconsider those stances. I rest my case!

To summarize, make sure that your SOA initiative shares some if not all of the eight characteristics of successful SOA implementations. There has been so much chatter about SOA failures as of late. Now that we have six great examples of SOA successes, we should take the best practices that these companies used and put them to use in our projects so we can get shot at next year's prize.

Why Mashups Matter

Check out this SlideShare Presentation:

Why Mashups Matter

View more presentations from balajidhananjayan.

Mashups: The Small Business Applications

While the business world races to catch up with Web 2.0 applications like wikis, RSS feeds, and widgets, the “next thing” is already here and starting to catch on fast: mashups

Mashups are a hybrid genre of Web applications that borrow from two or more other Web applications or data sources and then literally mash them up into one unique application. For example, a company called Infopia has developed a mashup that eBay sellers can use combining the data from their online stores with the tools of Salesforce.com, such as customer relationship management (CRM), inventory management, and online performance analytics.

Anyone can do it

The beauty of the mashup is how easy it is to build them. It’s basically a three-step process:

1. Choose the data sources or applications you want to mashup. This can be any combination of an internal database with a widely used application programming interface (API) from a source like Amazon.com, Google Maps, Flickr, or eBay. There are countless other APIs available to mix and match. Other ways to access data include Web feeds, like RSS, and screen scraping. Screen scraping involves using a simple program that “scrapes” data from the display output on a website.
   
   
2. Take a feed from each source and aggregate it into one mashup. This may sound like the most intimidating step. It’s not. Actually, finding the tools to build the mashup is easy. It’s more difficult finding the data. Some of the most popular mashup tools and servers include Yahoo Pipes, Microsoft Pop Fly, and Kapow Technologies. Google has a mashup editor in beta, as well. All are easy to use for the non-techie.
   
   
3. Host it. You’ll need a domain host or Web server technology that supports server-side scripting technologies like PHP or Ruby on Rails. Many mashup authors are using a company called Dreamhost. It’s cheap, well reviewed by customers and is easy to use.
   

Mashups may be good for business

Like social networking sites and other Web 2.0 trends, it’s consumers that tend to be the early adopters with the business community coming along eventually. The same seems to be true with mashups.

Some of the most publicized mashups include Weather Bonk, a mashup site that combines Yahoo! Traffic with Google Maps and various weather feeds that come up with one page featuring live traffic cams and a weather map customized by location.

However, it is the business realm where mashups will likely have their greatest impact. It’s already starting to happen. I see the following trends in business mashups:

• Data visualization. So far, this means leveraging geographical information with other data feeds. Google Maps, by far, is the most popular API used in mashups. Imagine, for example, combining Google Maps with a realtor’s feed of multiple listings in her market, combined with school district borders and educational rankings.

• Credit card processing. A popular mashup with online retailers is mashing up external credit card processing from the banks with internal e-commerce orders.

• Call center applications. Customer representatives taking calls and following up on orders by phone typically are staring at more than one screen: one of the website and the online order, the other displaying the CRM screen. We are seeing more online retailers mashing up the two (the e-commerce component with the CRM) into one view, one screen.

Mashups and the IT department

Hybrid Web applications tailor made by the user? That sounds like the makings of a migraine for the IT department. Issues to be considered include security and integration with other applications on the company network, just for starters. However, most IT managers have already learned from the proliferation and easy access of Web 2.0 tools that they’re fighting a losing battle retaining control of what online tools employees use.

I would offer the following advice to antsy IT directors: “Think of it as experimental. If the mashup proves beneficial to the business, then IT has a prototype to take and perfect.”

Business Mashups for Financial Services

Business mashups - mashup applications for and by the business are new applications combining the best of consumer mashups and data mashups with a strong process component.

Business mashups are a key component of integrating business and data services, as mashup technologies provide the ability to develop new integrated services quickly, to combine internal services with external or personalized information, and to make these services tangible to the business user through user interfaces.

The financial services industry has been an early adopter of business-driven initiatives using SOA and mashups. Needless to say, this market has other things on its mind just now. The question we are all asking is, "What's in store for us given the meltdown?" I've been building mashups for a handful of global banks for the past nine months, and I've got some opinions about what we can expect for the next nine months.

Mashups in the financial sector aren't just for the back office. I understand that Financial institutions have to be conservative. When bankers and investment institutions stray from the straight and narrow, somebody will likely be in front of Parliament right before they go to jail. So while I understand their reluctance to adopt mashups on the front-end of their business, I think it is a mistake. I wouldn’t expose the banking systems until we get better mashup security. But financial institutions have a lot of other offerings that aren’t tied directly to their transactional back-end systems.

Financial institutions have to walk a fine line. They are in a constant struggle to balance the need for governance, the heavy load of compliance, and a cutthroat competitive landscape. And the financial sector depends heavily on technology to be competitive. And not necessarily technology within a traditional IT organization.

According to a study, for every rupee spent on ‘real’ IT, most industries also spend 60 paisa on ‘shadow IT.’ That is, IT funded directly by, and implemented within the business. In the financial sector I’d be willing to bet the ratio is much higher. One bank employee I talked to said that embedding IT within the business is a necessary practice just to stay competitive. When one bank innovates, the others have to be right behind. That means tight coupling between the technologists and the business so new and innovative offerings can be out the door fast.

This sounds like a perfect job for mashups.

As a consumer of financial services, I’ve got a number of ideas for how they could use mashups without compromising their core banking systems.

I have accounts with several investment firms, yet when I want to do any investment research, I have to search Yahoo! finance to get the financials and Google for any relevant news. I’d use a mashup that pulled that information together into a single page.

How about a mashup that pulls together many investment strategies? Mashing up books from Amazon and information from some of the leading personal finance strategists. How about a mashup that lets me compare and contrast a company’s performance against some of its nearest competitors? Then mash in some Google Docs to let me save my analysis so I can retrieve it later.

I’m not buying that mashups aren’t a good fit for the financial services industry. Most of the innovation, at least on the consumer side, isn’t in the back-end transactional systems. It’s out front, providing services, information and advice to customers.

Eight ways to get developers on board with SOA governance

Does ramming SOA down the development organization help the cause of service orientation? Of course not. But, many companies have taken this tact, attempting to coax developers to adopt SOA practices with little or no input, guidance, or training.

Too many organizations, attempt to take shortcuts to SOA, and in the process, shortchange governance, which would help get developers on board with the effort. Plus, many developers are bogged down with routine maintenance tasks — which still occupy a lion’s share of time. (Though SOA can help cut down maintenance costs and make more funds available for business-growth projects.)

Efforts to force SOA on developers — the top-down approach — without their active input into the design-time aspects result in frustration and cynicism.

Developer disenchantment, of course, cuts into the benefits we want to see from SOA, such as increased ROI on software investments, augmented organizational agility, and diminished IT maintenance burdens. Service-oriented methodologies can help organizations navigate through today’s rough-and-tumble economy, and be well positioned to grow as things pick up. (And they will pick up… there are green shoots already forming…)

Of course, as companies miss the SOA boat, the finger-pointing starts — and guess who gets the blame? Far too many enterprises attribute any SOA disappointments as being exclusively caused by recalcitrant developers sabotaging well-intentioned governance efforts. The real blame should be pinned on management, and a failure to actively involve developers in the governance process. (Or a failure to even have a governance process, period.)

Here are some recommendations to bringing developers into the SOA process:

1. Don’t compensate on the basis of volume. Recognize that number of lines of code written isn’t a valid productivity metric anymore.

2. Compensate for working smarter. Reward developers for reusing others’ work.

3. There are times when new code is needed, and recognize that. Also reward developers for writing reusable services when no applicable services exist.

4. But don’t let people go too far with rewarding reusable service creation. Penalize developers who unnecessarily create new services (or otherwise violate governance standards).

5. But don’t punish developers for the overhead (and inevitable schedule impacts) mandated by adherence to solid SOA design and governance methodologies.

6. Make runtime governance consistent across all teams — even consultants or outsourced development teams.

7. Recognize the need for new skill-sets (e.g., service and policy custodians, technical communications specialists, etc.) in support of SOA and related governance.

8. Educate development managers in cross-departmental support requirements.