As we've been looking at cloud computing over the past several years, a long transition is under way, of moving from traditional IT and architectural method to this notion of cloud -- be it private cloud, at a third-party location, or through some combination of the above.

Traditional capacity planning is not enough in these newer cloud-computing environments. Elasticity planning is what’s needed. It’s a natural evolution of capacity planning, but it’s in the cloud.

Therefore traditional capacity planning needs to be reexamined. So now we'll look at how to best right-size cloud-based applications, while matching service delivery resources and demands intelligently, repeatedly, and dynamically. The movement to pay-per-use model also goes a long way to promoting such matched resources and demand, and reduces wasteful application practices.

We'll also examine how quality control for these cloud applications in development reduces the total cost of supporting applications, while allowing for a tuning and an appropriate way of managing applications in the operational cloud scenario.

Ashizawa: Old-fashioned capacity planning focuses on the peak usage of the application, and it had to, because when you were deploying applications in-house, you had to take into consideration that peak usage case. At the end of the day, you had to be provisioned correctly with respect to compute power. Oftentimes with long procurement cycles, you'd have to plan for that.

In the cloud, because you have this idea of elasticity, where you can scale up your compute resources when you need them, and scale them back down, obviously that adds another dimension to old-school capacity planning.

The new way look at it within the cloud is elasticity planning. You have to factor in not only your peak usage case, but your moderate usage case and your low-level usage as well. At the end of the day, if you are going to get the biggest benefit of cloud, you need to understand how you're going to be provisioned during the various demands of your application.

If you were to take, for instance, the old-school capacity-planning ideology to the cloud, you would provision for your peak use-case. You would scale up your elasticity in the cloud and just keep it there.

But if you do it that way, then you're negating one of the big benefits of the cloud. That's this idea of elasticity, and paying for only what you need at that moment.

One of the main factors why people consider sourcing to the cloud is because you have this elastic capability to spin up compute resources when usage is high and scale them back down when the usage is low. You don’t want to negate that benefit of the cloud by keeping your resource footprint at its highest level.

[Editor's Note: On Dec. 16, HP announced three new offerings designed to enable cloud providers and enterprises to securely lower barriers to adoption and accelerate the time-to-benefit of cloud-delivered services.

Ashizawa: What we're now bringing to the market works in all three cases [of cloud capacity planning]. Whether you're a private internal cloud, doing a hybrid model between private and public, or sourcing completely to a public cloud, it will work in all three situations.

The new enhancement that we're announcing now is assurance for cost control in the cloud. Oftentimes enterprises do make that step to the cloud, and a big reason is that they want to reap the benefits of the cost promise of the cloud, which is to lower cost. The thing here, though, is that you might fall into a situation where you negate that benefit.

If you deploy an application in the cloud and you find that it’s underperforming, the natural reaction is to spin up more compute resources. It’s a very good reaction, because one of the benefits of the cloud is this ability to spin up or spin down resources very fast. So no more procurement cycles, just do it and in minutes you have more compute resources.

The situation, though, that you may find yourself in is that you may have spun up more resources to try to improve performance, but it might not improve performance. I'll give you a couple of examples.

You can find yourself in a situation where your application is no longer right-sized in the cloud, because you have over-provisioned your compute resources.

If your application is experiencing performance problems because of inefficient Java methods, for example, or slow SQL statements, then more compute resources aren't going to make your application run faster. But, because the cloud allows you to do so very easily, your natural instinct may be to spin up more compute resources to make your application run faster.

When you do that, you find yourself in is a situation where your application is no longer right-sized in the cloud, because you have over provisioned your compute resources. You're paying for more compute resources and you're not getting any return on your investment. When you start paying for more resources without return on your investment, you start to disrupt the whole cost benefit of the cloud.

Applications need to be tuned so that they are right-sized. Once they are tuned and right-sized, then, when you spin up resources, you know you're getting return on your investment, and it’s the right thing to do.

Whether you have existing applications that you are migrating to the cloud, or new applications that you are deploying in the cloud, Cloud Assure for cost control will work in both instances.

Cloud Assure for cost control solution comprises both HP Software and HP Services provided by HP SaaS. The software itself is three products that make up the overall solution.

The first one is our industry-leading Performance Center software, which allows you to drive load in an elastic manner. You can scale up the load to very high demands and scale back load to very low demand, and this is where you get your elasticity planning framework.

Moderate and peak usage

Ashizawa: The second solution from a software’s perspective is HP SiteScope, which allows you to monitor the resource consumption of your application in the cloud. Therefore, you understand when compute resources are spiking or when you have more capacity to drive even more load.

The third software portion is HP Diagnostics, which allows you to measure the performance of your code. You can measure how your methods are performing, how your SQL statements are performing, and if you have memory leakage.

When you have this visibility of end user measurement at various load levels with Performance Center, resource consumption with SiteScope, and code level performance with HP Diagnostics, and you integrate them all into one console, you allow yourself to do true elasticity planning. You can tune your application and right-size it. Once you've right-sized it, you know that when you scale up your resources you're getting return on your investment.

You want to get a grasp of the variable-cost nature of the cloud, and you want to make this variable cost very predictable. Once it’s predictable, then there will be no surprises. You can budget for it and you could also ensure that you are getting the right performance at the right price. ... If you're thinking about sourcing to the cloud and adopting it, from a very strategic standpoint, it would do you good to do your elasticity planning before you go into production or you go live.

The crucial migration phase when moving or modernizing data centers can make or break the success of these complex undertakings. Much planning and expensive effort goes into building new data centers, or in conducting major improvements to existing ones. But too often there's short shrift in the actual "throwing of the switch" -- in the moving and migrating of existing applications and data.

But, as new data center transformations pick up -- due to the financial pressures to boost overall IT efficiency -- so too should the early-and-often planning and thoughtful execution of the migration itself get proper attention. This podcast examines the best practices, risk mitigation tools, and requirements for conducting data center migrations properly.

Bennett: We see a great deal of activity in the marketplace right now of people designing and building new data centers. They have this wonderful new showcase site, and they have to move into it.

The reasons for this growth, the reasons for moving to other data centers, are fueled by a lot of different activities.

In many cases it's related to growth. The organization and the business have been growing. The current facilities were inadequate -- because of space or energy capacity reasons or because they were built 30 years ago -- and so the organization decides that it has to either build a new data center or perhaps make use of a hosted data center. As a result, they are going to have to move.

Whether they're moving to a data center they own, moving to a data center owned and managed by someone else, or outsourcing their data center to a vendor like HP, in all cases you have to physically move the assets of the data center from one location to another.

The impact of doing that well is awfully high. If you don't do it well, you're going to impact the services provided by IT to the business. You're very likely, if you don't do it well, to impact your service level agreements (SLAs). And, should you have something really terrible happen, you may very well put your own job at risk.

So, the objective here is not only to take advantage of the new facilities or the new hosted site, but also to do so in a way that ensures the right continuity of business services. That ensures that service levels continue to be met, so that the business, the government, or the organization continues to operate without disruption, while this takes place. You might think of it, as our colleagues in Enterprise Services have put it, as changing the engine in the aircraft while it's flying.

Gilis: If you don't do the planning, if you don't know where you're starting from and where you're going to, then it's like being on the ocean. Going in any direction will lead you anywhere, but it's probably not giving you the path to where you want to go. If you don't know where to go to, then don't start the journey.

Most of the migrations today are not migration of the servers, the assets, but actually migration of the data. You start building a next-generation data center --most of the time with completely new assets that better fit what your company wants to achieve.

Migration is actually the last phase of a data center transformation. The first thing that you do is a discovery, making sure that you know all about the current environment, not only the servers, the storage, and the network, but the applications and how they interact. Based on that, you decide how the new data center should look.

... If you build your new engine, your new data center, and you have all the new equipment inside, the only thing that you need to do is migrate the data. There are a lot of techniques to migrate data online, or at least synchronize current data in the current data centers with the new data center.

Usually, what you find out is that you did not do a good enough job of assessing the current situation, whether that was the assessment of a hardware platform, server platform, or the assessment of a facility.

There's not that much difference between local storage, SAN storage, or network attached storage (NAS) and what you designed. The only thing that you design or architect today is that basically every server or every single machine, virtual or physical, gets connected to a shared storage, and that shared storage should be replicated to a disaster recovery site.

That's basically the way you transfer the data from the current data centers to the new data centers, where you make sure that you build in disaster recovery capabilities from the moment you do the architecture of the new data center. ... The moment you switch off the computer in the first data center, you can immediately switch it on in the new data center.

McKinnis: From an outsourcing perspective, companies don't always do 100 percent outsourcing of that data-center environment or that shared computing environment. It may be part of it. Part of it they keep in-house. Part of it they host with another service provider.

What becomes important is how to manage all the multiple moving parts and the multiple service providers that are going to be involved in that future mode of operation. It's accessing what we currently have, but it's also designing what that future mode needs to look like.

There are all sorts of decisions that go around that from a client perspective to get to that decision. In many cases, if you look at it from a technology standpoint, the point of decision is something around getting to an end of life on a platform or an application. Or, there is a new licensing cycle, either from a support standpoint or an operating system standpoint.

There is usually something that happens from a technology standpoint that says, "Hey look, we've got to make a big decision anyway. Do we want to invest going this way, that we have gone previously, or do we want to try a new direction?"

Once they make that decision, we look at outside providers. It can take anywhere from 12 to 18 months to go through the full cycle of working through all the proposals and all the due diligence to build that trust between the service provider and the client. Then, you get to the point, where you can actually make the decision of, "Yes, this is what we are going to do. This is the contract we are going to put in place." At that point, we start all the plans to get it done.

. . . There are times when deals just fall apart, sometimes in the middle, and they never even get to the contracting phase.

There are lots of moving parts, and these things are usually very large. That's why, even though outsourcing contracts have changed, they are still large, are still multi-year, and there are still lots of moving parts.

Bennett: The elements of trust come in, whether you're building a new data center or outsourcing, because people want to know that, after the event takes place, things will be better. "Better" can be defined as: a lot cheaper, better quality of service, and better meeting the needs of the organization.

This has to be addressed in the same way any other substantial effort is addressed -- in the personal relationships of the CIO and his or her senior staff with the other executives in the organization, and with a business case. You need measurement before and afterward in order to demonstrate success. Of course, good, if not flawless, execution of the data center strategy and transformation are in play here.

The ownership issue may be affected in other ways. In many organizations it's not unusual for individual business units to have ownership of individual assets in the data center. If modernization is at play in the data center strategy, there may be some hand-holding necessary to work with the business units in making that happen. This happens whether you are doing modernization and virtualization in the context of existing data centers or in a migration. By the way, it's not different.

Be aware of where people view their ownership rights and make sure you are working hand-in-hand with them instead of stepping over them. It's not rocket science, but it can be very painful sometimes.

Gilis: You have small migration and huge migrations. The best thing is to cut things into small projects that you can handle easily. As we say, "Cut the elephant in pieces, because otherwise you can't swallow it."

Should be a real partnership

And when you work with your client, it should be a real partnership. If you don't work together, you will never do a good migration, whether it's outsourcing or non-outsourcing. At the end, the new data center must receive all of the assets or all of the data -- and it must work.

If you do a lot of migrations, and that's actually what most of the service companies like HP are doing, we know how to do migrations and how to treat some of the applications migrated as part of a "migration factory."

We actually built something like a migration factory, where teams are doing the same over and over all the time. So, if we have to move Oracle, we know exactly how to do this. If we have to move SAP, we know exactly how to do this.

That's like building a car in a factory. It's the same thing day in and day out, everyday. That's why customers are coming to service providers. Whether you go to an outsourcing or non-outsourcing, you should use a service provider that builds new data centers, transforms data centers, and does migration of data centers nearly every day.

Most of the time, the people that know best how it used to work are the customers. If you don't work with and don't partner directly with the customer, then migration will be very, very difficult. Then, you'll hit the difficult parts that people know will fail, and if they don't inform you, you will have to solve the problem.

McKinnis:Cloud computing has put things back in people's heads around what can be put out there in that shared environment. I don't know that we've quite gotten through the process of whether it should be at a service provider location, my location, or within a very secure location at an outsourced environment.

Where to hold data

I don't think they've gotten to that at the enterprise level. But, they're not quite so convinced about giving users the ability to retain data and do that processing, have that application right there, held within that confinement of that laptop, or whatever it happens to be that they are interacting with. They're starting to see that it potentially should be held someplace else, so that the risk of that data isn't held at the local level.

Bennett: Adopting a cloud strategy for specific business services would let you take advantage of that, but in many of these environments today cloud isn't a practical solution yet for the broad diversity of business services they're providing.

We see that for many customers it's the move from dedicated islands of infrastructure, to a shared infrastructure model, a converged infrastructure, or an adaptive infrastructure. Those are significant steps forward with a great deal of value for them, even without getting all the way to cloud, but cloud is definitely on the horizon.

I had the pleasure to recently sit down with Purohit to examine how CIOs are managing their IT budgets for 2010. During the economic recovery, the cost-containment conundrum of "do more for less" -- that is, while still supporting all of your business requirements -- is likely to remain the norm.

So this discussion centers on how CIOs are grappling with implementing the best methods for higher cost optimization in IT spending, while also seeking the means to improve innovation and business results. The interview coincides with HP's announcements this week at Software Universe in Germany on fast-tracks to safer cloud computing.

"Every CIO needs to be extremely prepared to defend their spend on what they are doing and to make sure they have a great operational cost structure that compares to the best in their industry," says Purohit.

Purohit: Well, just about every CIO I've talked to right now is in the middle of planning their next year’s budget. Actually, it's probably better to say preparing for the negotiation for next year’s budget. There are a couple of things.

The good news is that this budget cycle doesn’t look like last year’s. Last year’s was very tough, because the financial collapse really was a surprise to many companies, and it required people to very quickly constrain their capital spend, their OPEX spend, and just turn the taps off pretty quickly.

... [Now] they need to be able to prepare to make a few big bets, because the reality is that the smartest companies out there are using this downturn as an advantage to make some forward looking strategic bets. If you don't do that now, the chances are that, two years from now, your company could be in a pretty bad position.

... There are a couple of pretty important things to get done. The first is to have an extremely good view of the capital you have, and where it is in the capital cycle. Getting all of that information that is timely, accurate, and at your fingertips, so you can enter the planning cycle, is extraordinarily important and fundamental.

When you are going to deploy new capital, always make sure that it's going to be able to be maintained and sustained in the lowest-cost way. The way we phrase this is, "Today's innovation is tomorrow’s operating cost."

When you do refresh, there are some great new ways of actually using capital on server storage and networking that's at a much lower cost structure, and much easier to operate, than the systems we had three or four years ago.

In the past, we’ve seen mistakes made, where people deployed new capital without really thinking how they were going to drive the long-term cost structure down in operating that new capital.

Companies want to see the CIOs use capital to support the most important business initiatives they have, and usually they are associated with revenue growth, by expanding the sales force, and new business units, some competitive program, or eventually a new ecommerce presence.

It's imperative that the CIO shows as much as possible that they're applying capital to things that clearly align with driving one of those new business agendas that's going to help the company over the next three years.

Now, in terms of how you do that, it's making sure that the capital spend that you have, that everything in the data center you have, is supporting a top business priority. It's the most important thing you can do.

One thing that won't change is that demand from the business will all of a sudden strip your supply of capital and labor. What you can do is make sure that every person you have, every piece of equipment you have, every decision you are making, is in the context of something that is supporting an immediate business need or a key element of business operation.

It also means there are more things and more new things to manage.

There are lots of opportunities to be disciplined in assessing your organization, both in how you spend capital, how you use your capital, and what your people are working on. I wouldn't call it waste, but I would call it just a better discipline and whether what you're doing truly is business critical or not.

If you don't get the people and process right, then new technologies, like virtualization or blade systems, are just going to cause more headaches downstream, because those things are fantastic ways of saving capital today. Those are the latest and greatest technologies. Four or five years ago, it was Linux and Windows Server.

It also means there are more things and more new things to manage. If you don't have extremely disciplined processes that are automated, and if you don't have all of your team with one play book on what those processes are, and making sure that there is a collaborative way for them to work on those processes, and which is as automated as possible, your operating costs are just going to increase as you embrace the new technologies that lower your capital. You've got to do both at the same time.

Say that you're a new CIO coming to organization and you see a lack of standardization, a lack of centers of excellence, and a lot of growth through merger and acquisition, there is a ton of opportunity to take out operating cost.The right governance

We've seen customers generally take out 5 to 10 percent, when a new CIO comes on board, rationalizes everything that's being done, and introduces rigorous standardization. That's a quick win, but it's really there for companies that have been probably a little earlier in the maturity cycle of how they run IT.

A couple of new things that are possible now with the outsourcing model and the cloud model -- whether you want to call it cloud or software as a service (SaaS) -- is that there's an incredibly rich marketplace of boutique service shops and boutique technology providers that can provide you either knowledge or technology services on-demand for a particular part of your IT organization.

The cost structures associated with running infrastructure as a service (IaaS) are so dramatically lower and are very compelling, so if you can find a trusted provider for that, cloud computing allows you to move at least markets that are lower risk to experiment with those kind of new techniques.

The other nice thing we like about cloud computing is that there is at least a perception that is going to be pretty nimble, which means that you'll be able to move services in and out of your firewall, depending on where the need is, or how much demand you have.

In contrast to rivals like Pegasystems, which has a very complex, rule-driven approach, Lombardi’s approach has always been characterized by simplicity. In that sense, its approach mimicked that of Fuego before it was acquired by BEA, which of course was eventually swallowed up by Oracle.

We echo Sandy Kemsley’s thoughts of letdown about hopes for a Lombardi IPO. But even had the IPO been done, that would have postponed the inevitable. We agree with her that if IBM is doing this acquisition anyway, it makes sense to make Lombardi a first-class citizen within the IBM WebSphere unit.

Not surprisingly, IBM is viewing Lombardi for its simplicity. At first glance, it appears that Lombardi Teamworks, their flagship product, overlaps WebSphere BPM. Look under the hood, and WebSphere BPM is not a single engine, but the product of several acquisitions and internal development, including the document-oriented processes of FileNet and the application integration processes from Crossworlds.

So in fact Lombardi is another leg of the stool, and one that is considerably simpler than what IBM already has. In fact, this is vey similar to how Oracle has positioned the old Fuego product alongside its enterprise BPM offering which is build around IDS Scheer’s ARIS modeling language and tooling.

IBM’s strategy is that Lombardi provides a good way to open the BPM discussion at department level. But significantly on today's announcement call, IBM stated that once the customer wants to scale up, that it would move the discussion to its existing enterprise-scale BPM technology. It provided an example of a joint engagement at Ford -– where Lombardi works with the engineering department, while IBM works at the B2B trading partner integration level -- as an example of how the two pieces would be positioned going forward.

The challenge for IBM is preserving the simplicity of Lombardi products, which tend to be more department oriented bottom-up, vs. the IBM offerings that are enterprise-scale and top-down.

James Governor of RedMonk had a very interesting suggestion that IBM could leverage the Lombardi technologies atop some of its Lotus collaboration tools. We also see good potential synergies with the vertical industry frameworks as well.

The challenge for IBM is preserving the simplicity of Lombardi products, which tend to be more department-0oriented and bottom-up vs. the IBM offerings that are enterprise-scale and top-down. Craig Hayman, general manager of the application and integration middleware (WebSphere) division, admitted on the announcement call that IBM has “struggled” in departmental, human-centric applications. In part that is due to IBM’s top-down enterprise focus, and also the fact that all too often, IBM’s software is known more for richness than ease of use.

A good barometer of how IBM handles the Lombardi integration will be reflected on how it handles Lombardi Blueprint and IBM WebSphere BlueWorks BPM. Blueprint is a wonderfully simple process definition hosted service while BlueWorks is also hosted, but is far more complex with heavy strains of social computing.

We have tried Blueprint and found it to be a very straightforward offering that simply codifies your processes, generating Word or PowerPoint documentation, and BPMN models. The cool thing is that if you use it only for documentation, you have gotten good value out of it – and in fact roughly 80 percent of Blueprint customers simply use it for that.

On today's call, Hayman said that IBM plans to converge both products. That's a logical move. But please, please, please, don’t screw up the simplicity of Blueprint. If necessary, make it a stripped down face of BlueWorks.

Timing here is critical. As the end users of cloud services seek flexible infrastructure, IP voice, unified communications and call center automation, cloud providers need a fast-track to such low-risk cloud capabilities. HP is also wasting no time as it competes yet more broadly against Cisco Systems in the race to become mainstream means to cloud services.

HP Operations Orchestration, which will automate the provisioning of services within the existing infrastructure, allowing businesses to seamlessly increase capacity through integration with such things as Amazon Elastic Compute Cloud. Look for other public cloud providers to offer this as well.

HP Communication as a service (CaaS), a cloud program that will enable service providers to offer small and mid-size businesses services delivered on an outsourced basis with utility pricing. CaaS includes an aggregation platform, four integrated communications services from HP and third parties, as well as the flexibility to offer other on-demand services.

HP Cloud Assure for Cost Control, designed to help companies optimize cloud costs and gain predictability in budgeting by ensuring that they right-size their compute footprints.

"When we first launched Cloud Assure earlier this year, we focused on the top three inhibitors, which were security of applications in the cloud, performance of applications in the cloud, and availability of applications in the cloud. We wanted to provide assurance to enterprises that their applications will be secure, they will perform, and they will be available when they are running in the cloud.

"The new enhancement that we're announcing now is assurance for cost control in the cloud. Oftentimes enterprises do make that step to the cloud, and a big reason is that they want to reap the benefits of the cost promise of the cloud, which is to lower cost."

He then explained how Cloud Assure for cost control works:

"Cloud Assure for cost control solution comprises both HP Software and HP Services provided by HP SaaS. The software itself is three products that make up the overall solution.

"The first one is our industry-leading Performance Center software, which allows you to drive load in an elastic manner. You can scale up the load to very high demands and scale back load to very low demand, and this is where you get your elasticity planning framework.

"The second solution from a software’s perspective is HP SiteScope, which allows you to monitor the resource consumption of your application in the cloud. Therefore, you understand when compute resources are spiking or when you have more capacity to drive even more load.

"The third software portion is HP Diagnostics, which allows you to measure the performance of your code. You can measure how your methods are performing, how your SQL statements are performing, and if you have memory leakage."

These HP-driven means to attain cloud benefits sooner than later come in response to recent surveys in which industry executives clearly stated a need for more flexible computing options in the face of uncertain economic times. They want to be able to dial up and down their delivery of services, but without the time and cost of building out the capital-intensive traditional delivery models.

The market is also looking to cloud services -- be they on-premises, from third-parties or both -- to provide:

Elasticity – the ability to rapidly respond to changing business needs with automated provisioning of cloud and physical services

Cost control – by optimizing efficiency and gaining predictability of costs by ensuring cloud compute resources are “right sized” to support fluctuating business demands

Risk reduction – through automated service provisioning that reduces manual errors, non-compliance snafus, and downtime of business services and processes.

I think HP has correctly identified a weakness in the SaaS and cloud markets. In many cases, applications and productivity services came to market first, but lacked the enterprise-caliber infrastructure, management, and auditing and fiscal control mechanisms. Now, HP is bringing these traditional IT requirements to the cloud domains, and making them available to the large market of existing providers.

The cloud horse is now in front of the cart, which means the providers can do their jobs better, and more end users can adopt secure cloud services in ways that reassure their mangers and adhere to their governance policies.BriefingsDirect contributor Carlton Vogt provided editorial assistance and research on this post.You may also be interested in:

Fujitsu says its new solution will allow companies migrate existing multi-platform and multi-vendor mission-critical systems to enterprise clouds. The benefit of this is that it will remove capital-intensive investments in technology and replace them with a pay-as-you-go strategy.

Designed for enterprises in manufacturing, finance, healthcare, retail and other compute- and data-intensive industries, Fujitsu's cloud solutions include system construction, operations, maintenance services and full-featured vertical applications. In order to comply with vertical industry standards and regulations, retail transactional applications will be hosted in a payment-card industry (PCI) compliant data center and health care applications will be hosted in a health insurance portability and accountability act (HIPAA) compliant environment.

Going green

In addition, the multi-million dollar data-center upgrade and expansion will more than double available raised floor space, reduce carbon emissions by 21 percent, and increase available power and cooling capabilities that will dramatically expand the data center’s effective capacity by over 800 percent.

. . . Upgrade and expansion will . . . reduce carbon emissions by 21 percent, and increase available power and cooling capabilities that will dramatically expand the data center’s effective capacity by over 800 percent.

Among the first ISVs to take advantage of the new cloud services offerings are CoolRock Software, an ISV specializing in email management software for archiving, ediscovery and collaboration, and Intershop Communications, a leading ecommerce solutions ISV.

Monday, December 7, 2009

TIBCO Software will release in 2010 software that lets people search for and then track corporate information by subject matter in a similar way to how they might follow people on Twitter.

This is a clear sign that the enterprise software and social software worlds are munging. Get ready to see a lot more.

The idea behind the tibbr – the name an obvious play on “Twitter” -- helps people find information related to their particular tasks and jobs quickly and easily by searching for information based on its subject matter, and then subscribing to relevant feeds on those topics, the company said. [Disclosure: TIBCO is a sponsor of BriefingsDirect podcasts.]

Lack of information isn’t the main problem for enterprise systems these days, what's really needed is a useful interface and method for getting to the precise needed information quickly and easily to help business workers do their jobs more efficiently. By taking a page out of the social networking playbook, TIBCO aims to let people access corporate information via a Twitter-like "update." The result: workers can find the information they need faster, so, in theory, they perform with far higher productivity.

With people spending – or arguably wasting -- so much time on social-networking applications outside of their everyday work tasks, companies have been looking for ways to apply social-networking technologies like real-time collaboration, status updates and Web presence information inside the firewall. TIBCO obviously sees tibbr as one way to do it.

I expect we'll see more ways that the social wall interface makes it's way into the business IT domain. This interface could easily replace the email in-box as the place workers tend to "live" during their jobs. Google Wave clearly also sees this as a good fit.

And, of course, no one "wall" will do. We should also expect an aggregation of walls that will follow us, and also adapt in terms of what takes priority on the personalized wall -- automated via policies -- based on what we are doing. Or where we are doing it. Or both.

As TIBCO describes tibbr, it will let people set “subjects” that represent a user, an application or a process relevant to what tasks or functions someone performs in an organization. Through tibbr, they can subscribe to feeds by category – for example, Finance or Accounts Payable -- for specific information they think will be relevant to their jobs.

Tibbr is based on Silver, TIBCO’s own cloud-computing infrastructure platform. TIBCO unveiled Silver earlier this year as a rapid-application development and delivery system for companies that want to deploy cloud computing but are unsure how to get started.

The company also is pushing tibbr’s foundation on open standards as an advantage for companies that want to integrate it with other applications so it can become a part of someone’s daily workflow.

TIBCO plans to test tibbr out on its own employees beginning on Dec. 14 before rolling it out to customers in early 2010.

BriefingsDirect contributor Elizabeth Montalbano provided editorial assistance and research on this post.

Welcome to the latest BriefingsDirect Analyst Insights Edition, Vol. 47. Our topic this week on BriefingsDirect Analyst Insights Edition centers on how to define, track and influence how people actually adapt to and adopt technology.

Any new information technology might be the best thing since sliced bread, but if people don’t understand the value or how to access it properly -- or if adoption is spotty, or held up by sub-groups, agendas, or politics -- then the value proposition is left in the dust. Perceptions count ... a lot.

A crucial element for avoiding and overcoming social and user dissonance with technology adoption is to know what you are up against, in detail. Yet, data and inferences on how people really feel about technology is often missing, incomplete, or inaccurate.

In this discussion, we hear from two partners who are working to solve this issue pragmatically. First, with regard to Enterprise 2.0 technologies and approaches. And, if my hunch is right, it could very well apply to service-oriented architecture (SOA) adoption as well.

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.

Hinchcliffe: ... As many of you know, we've been spending a lot of time over the last few years talking about how things like Web 2.0 and social software are moving beyond just what’s happening in the consumer space, and are beginning to really impact the way that we run our businesses.

More and more organizations are using social software, whether this is consumer tools or specific enterprise-class tools, to change the way they work. At my organization, we've been working with large companies for a number of years trying to help them get there.

This is the classic technology problem. Technology improves and gets better exponentially, but we, as organizations and as people, improve incrementally. So, there is a growing gap between what’s possible and what the technology can do, and what we are ready to do as organizations.

I've been helping organizations improve their businesses with things like Enterprise 2.0, which is social collaboration, using these tools, but with an enterprise twist. There are things like security, and other important business issues that are being addressed.

Businesses are about collaboration, team work, and people working together . . .

But, I never had a way of dealing with the whole picture. We find that that folks need a deep introduction to what the implications are when you have globally visible persistent collaboration using these very social models and the implications of the business.

Michael Krigsman, of course, is famous for his work in IT project risk -- what it takes for projects to succeed and what causes them not to succeed. I saw this as the last leg of the stool for a complete way of delivering these very new, very foreign models, yet highly relevant models, to the way that organizations run their business.

Businesses are about collaboration, team work, and people working together, but we have used things like email, and models that people trust a lot more than these new tools.

There is usually a lot of confusion and uncertainty about what’s really taking place and what the expectations are. And Michael, with Asuret, brings something to the table. When we package it as a service that essentially brings these new capabilities, these new technologies and approaches, it manages the uncertainty about what the expectations are and what people are doing.

Krigsman: Think about business transformation projects -- any type. This can be any major IT project, or any other type of business project as well. What goes wrong? If we are talking about IT, it's very tempting to say that the technology somehow screws up. If you have a major IT failure, a project is late, the project is over budget, or the project doesn’t meet expectations or plan, it's extremely easy to point the finger at the software vendor and say, "Well, the software screwed up."

If we look a little bit deeper, we often find the underlying drivers of the project that is not achieving its results. The underlying drivers tend to be things like mismatched expectations between different groups or organizations.

For example, the IT organization has a particular set of goals, objectives, restrictions, and so forth, through which they view the project. The line of business, on the other hand, has its own set of business objectives. Very often, even the language between these two groups is simply not the same.

As another example, we might say that the customer has a particular set of objectives and the systems integrator has its own objectives for the particular project. The customer wants to get it done as fast and as inexpensively as possible. The systems integrator is often -- and I shouldn’t make generalizations, but -- interested in maximizing their own revenue.

If we look inside each of these groups, we find that inside the groups you have divisions as well, and these are the expectation mismatches that Dion was referring to.

If we look at IT projects or any type of business transformation project, what’s the common denominator? It's the human element. The difficulty is how you measure, examine, and pull out of a project these expectations around the table. Different groups have different key performance indicators (KPIs), different measures of success, and so forth, which create these various expectations.

Amplifying weak signals

How do you pull that out, detect it inside the project, and then amplify what we might call these weak signals? The information is there. The information exists among the participants in the project. How do you then amplify that information, package it, and present it in a way that it can be shared among the various decision-makers, so that they have a more systematic set of inputs for making decisions consistently based on data, rather than anecdote? That’s the common thread.

... We're not selling software. We offer a service, and the service provides certain results. However, we've developed software, tools, methods, techniques, and processes that enable us to go through this process behind the scenes very efficiently and very rapidly.

Rogers: What we discovered in our studies is that one of the fundamental needs in running any type of business project -- an SOA project or an Enterprise 2.0 IT project -- is the ability to share information and expose that visibility to all parties at levels that will resonate with what matters to them the most, but also bring them outside of their own domain to understand where dependencies exist and how one individual or one system can impact another.

One of the keys, however, is understanding that the measurements and the information need to get past system-level elements. If you design your services around what business elements are there and what matters to the business, then you can get past that IT-oriented view in bringing business stakeholders in aligned management and business goals to what transpires in the project.

Any way that you can get out -- web-based, easy-access dashboard with information -- and measure that regularly, you can allow that to proliferate through the organization. Having that awareness can help build trust, and that’s critical for these projects.

Baer: What Dion and Michael are talking about is an excellent idea in terms of that, in any type of environment where there is a lack of communication and trust, data is essential to really steer things. Data, and also assurances with risk management and protection of IT and all that. But, the fact is that there are some real clear hurdles.

An example is this project that my wife is working on at the moment. She was brought in as a consultant to a consulting firm that's working for the client, and each of them have very different interests. This is actually in a healthcare-related situation. They're trying to do some sort of compliance effort, and whoever was the fount of wisdom there postponed the most complex part of this problem to the very end. At the very end, they basically did a Hail Mary pass bringing a few more bodies.

They didn't look for domain expertise or anything. Essentially it's like having eight women be pregnant and having them give birth to a baby in a month. That's essentially the push they are doing.

On top of that, there is also a fear among each tribe of the other coming up with a solution that makes the other tribes look bad. So, I can't tell exactly the feedback from this, but I do know that my wife came in as a process expert. She had a pretty clear view on how to untie the bottlenecks.

Krigsman: We gather a lot of data. The essential elements have been identified during this conversation. ... It's absolutely accurate to look at this tribally. Tony spoke about tribal divisions and the social tribal challenges.

The fundamental trick is how to convert this kind of trust information. Jim was talking about collaborative project governance. All of this relates to the fact that you've got various groups of people. They have their own issues, their own KPIs, and so forth. How do you service issues that could impact trust and then convert that to a form that can then be examined dispassionately. I'd love to use the word "objectively," but we all know that being objective is a goal and it's never outcome that you can ultimately reach.

At least you have a way to systematically and consistently have metrics that you can compare. And then ... when you want to have a fight, at least you are fighting about KPIs, and you don't have people sitting in a conference room saying, "Well, my group thinks this. We believe the project 'blank.' If somebody says the same, my group thinks that." Well, let's have some common data that's collected across the various information silos and groups that we can then share and look at dispassionately.

Schmelzer: ... We think that the whole idea of project management is just an increasing fallacy in IT anyway. There is no such thing now. It's really a discrete project.

Can you really say that some enterprise software that you maybe buying or building yourself or maybe even sourcing as a service is really completely disconnected from all the other projects that you have going on or the other technology? The answer is, they are not.

The enterprise is a collection of many different IT projects, some of which are ongoing, some of which may have been perceived to be dead or no longer in development, or maybe some are in the future.

So, it's very hard to do something like discrete project management, where you have defined set of requirements and a defined timeline and defined budget, and make the assumption or the premise, which is false, that you're not going to be impacting any of the other concurrently running projects.

We think of this like a game of pick-up sticks. The enterprise is a collection of many different IT projects, some of which are ongoing, some of which may have been perceived to be dead or no longer in development, or maybe some are in the future. The idea that you could take any one of those little projects, and manipulate them without impacting the rest of the pile is clearly becoming false.

McKendrick: Michael and Dion, I think you're on the right track. In fact, it's all about organization. It's all about the way IT is organized within the company and, vice-versa, the way the company organizes the IT department. I’ll quote Mike Hammer, the consultant, not the detective, "Automate a mess and you get an automated mess." That's what's been happening with SOA.

Upper management either doesn't understand SOA or, if they do, it's bits and pieces -- do this, do that. They read Enterprise Magazine. The governance is haphazard, islands across the organization, tribal. Miko talks about this a lot in his talks about the tribal aspect. They have these silos and different interest groups conflicting.

There's a real issue with the way the whole process is managed. One thing I always say is that the organizations that seem to be getting SOA right, as Michael and Dion probably see with the Enterprise 2.0 world, are usually the companies that are pretty progressive. They have a pretty good management structure and they're able to push a lot of innovations through the organization.

Matsumura: ... This type of an approach really reflects the evolution of the best practice of adoption. Some of the themes that we've been talking about today around this sharing of information, communication, and collaboration, are really are essential for success.

I do want to caution just a little bit. People talk about complexity and they create a linkage between complexity and failure. It's more important to try to look at, first of all, the source of the problem. Complexity itself is not necessarily indicative of a problem. Sure, it's correlated, but ice-cream consumption is correlated with the murder rate, just as a function of when temperatures get hot, both things happen to increase. So complexity is also a measure of success and scale.

... The issue it comes down to for me is what Sandy said, which is that the word "trust," which is thrown in at the very end, turns out as extremely expensive. That alignment of organization and trust is actually a really important notion.

What happens with trust is that you can put things behind a service interface. Everything that's behind a service interface has suddenly gotten a lot less complex, because you're not looking at all that stuff. So, the reduction of complexity into manageability is completely dependent on this concept of trust and building it.

Kobielus: ... A dashboard is so important when you are driving a vehicle, and that's what a consolidated view of KPIs and metrics provides. They are a dashboard in the BI sense, and that's what this is, project intelligence dashboard for very complex project or mega programs that are linked projects. In other words, SOA in all of its manifestations.

In organization, you have to steer your enterprise in a different direction. You need obviously to bring together many projects and many teams across many business domains. They all need to have a common view of the company as a whole -- its operations, various stakeholders, their needs, and the responsibilities internally on various projects of various people. That's highly complex. So, it’s critical to have a dashboard that's not just a one-way conduit of metrics, from the various projects and systems.

In the BI world, which I cover, most of the vendors now are going like crazy to implement more collaboration and work-flow and more social community-style computing capabilities into their environments. It's not just critical to have everybody on the same page in terms of KPIs, but to have a sideband of communication and coordination to make sure that the organization is continuing to manage collectively according to KPIs and objectives that they all ostensibly agree upon.

Hinchcliffe: ... The way the process works is that we come into a client with an end-to-end service. Most organizations -- and this is going to be true of Enterprise 2.0 or SOA -- are looking at solving a problem. There's some reason why they think that this is going to help, but they're often not sure.

There are often a lot of unstated assumptions about how to apply technology to a business problem and what the outcome is going to be.

We start with this strategy piece that looks at the opportunity and tries to identify that for them and helps them correct the business case to understand what the return on investment (ROI) is going to be. To do that, you really have to understand what the needs of the organization are. So, one of the first things we do is bring Michael's process in, and we try and get ground truths.

There are often a lot of unstated assumptions about how to apply technology to a business problem and what the outcome is going to be. Particularly with SOA, you have so many borders that are typically involved. It's the whole concept around Conway's Law that the architecture tends to look back at the structure of the organization, because those are the boundaries in which everything runs.

One of the ways that we can assure that we have ground truth is by applying this dispassionate measurement process upfront to understand what people's expectations are, what their needs are, and what their concerns are. It's much more than just a risk-management approach. It's a way to get strategic project intelligence in a way that hasn't been possible before. We're really excited about it.

A lot of uncertainty

My specialty has always been focusing on emerging technology. There is always a lot of uncertainty, because people don't know necessarily what it is. They don't know what to expect. They have to have a way of understanding what that is, and you have an array of issues including the fact there are people who aren't willing to normally admit that they don't know things.

But, here is a way to safely and succinctly, on a regular basis, surface those issues and deal with them before they begin to have issues in the project. We then continue on through implementation and then regular assessments on the KPIs that can cause potential issues down the road. I think it's a valuable service. It's low impact, compared to another traditional interview process. This is something most organizations can afford to do on a regular basis.

Krigsman: ... I am so hesitant to use the term psychological, because it has so many connotations associated with it. But, the fact is that we spoke about perception earlier, and there has been a lot of discussion of trust and community and collaboration. All of these issues fundamentally relate to how people work together. These are the drivers of success, and especially the drivers of lack of success on projects of every kind.

It therefore follows that, if we want our projects to be governed well and to succeed, one way or another we have to touch and look at these issues. That’s precisely what we're doing with Asuret and it’s precisely the application that we have taken with Dion into Pragmatic Enterprise 2.0. You have to deal with these issues.