The adaptive web: Helping to bridge the CIO-CMO divide

This guest post comes courtesy of Dr. Scott Brave, co-founder and CTO of Baynote, a provider of digital marketing optimization solutions. He can be reached at brave@baynote.com.

By Dr. Scott Brave

CIO and CMO. Until very recently, many still believed these two roles couldn’t be more extreme in their differences. The stereotypical CMO was creative and guided by gut feel, whereas the CIO was steadfast, risk averse and driven by empirical evidence.

The emergence of the real-time web and its impact on customer expectations has pulled these two seemingly polar opposite disciplines much closer together. Real-time services like Twitter, Facebook and improved behavioral targeting technologies are pushing consumer expectations for instant, extremely personalized experiences to an all-time high.

This trend has forced the CIO and CMO to work in lockstep on digital marketing initiatives aimed at staying as close as possible to what the customer wants.

However, the reality is that while both sides understand their shared goals depend on working with the other, the relationship between the CIO and CMO is more often not a happy marriage. According to the CMO Council’s recent CMO-CIO Alignment Imperative report, there is a good amount of consensus among CMOs and CIOs on the central role of technology in improving the customer experience, but neither group feels like they are getting the job done.

Biggest struggle

Their single biggest struggle has become all about figuring out ways to adapt the experience – across the web as well as via mobile and email – to seemingly insatiable user expectations. This sentiment is consistent with recent M&A activity that signals the importance of web optimization technology: Adobe acquired Omniture last September; and IBM has gobbled up CoreMetrics, Unica, and most recently, Netezza for $1.7B.

The reality, however, is that current optimization approaches are still very manual and provide a rear-view mirror look at customer intent, making it impossible to target the customer in an accurate and scalable way. Alas, the CIO/CMO dilemma continues.

What we need is to build a smarter approach that allows companies to adapt to their customers’ needs in real-time.

What we need is to build a smarter approach that allows companies to adapt to their customers’ needs in real-time. The concept of collective intelligence, which I’ll address below, will be critical to achieving this vision -- something I like to think of as an “adaptive web.” That is, a digital experience that is always relevant and based on users’ current intent and interests. It also must be device-agnostic, especially important given the increased mobility of the online experience -- a challenge analyst firm Forrester calls “the Splinternet.”

The adaptive web is in fact central to what Gartner calls “Context-Aware Computing”, the idea that social analytics and computing will produce knowledge about individual context and preferences, allowing companies to predict and serve them what they want. According to Gartner, this model adapts interactions with the customer based on context, in contrast to today’s experience which is very reactive.

So, how close are we to building a truly end-to-end adaptive web?

To no surprise, there are numerous technical and psychological challenges for building an adaptive web. Namely, I see three primary roadblocks:

• Privacy Issues: To deliver adaptive experiences, we have to pay attention to what people are doing online in the first place. Different users have varying levels of comfort. We’ll have to find some sort of middle ground where the value of an adaptive experience greatly outweighs users’ privacy concerns.
  
  
• Deciding on the Method: Second, there’s determining the approach itself. Do we need a “metalayer” over the web? Some sort of toolbar or plug-in that could connect users’ entire web experiences across devices? Do ISPs need to get involved at the network level to watch every site users’ visit and how they engage with it? These are all options to consider – some more realistic than others - but the path is murky at best at this point.
  
  
• Determining Users’ Intents: The third obstacle is the biggest obstacle of all: pure science. It’s not a trivial problem to automatically pinpoint and serve up an experience based on a user’s current intent and context. As someone who has devoted his life’s work to studying human/computer interaction, I can’t emphasize this enough. Predicting what people want and need, and adapting their web experience in real-time is perhaps one of the remaining “big picture” challenges facing technologists.
  

Collective intelligence

Let’s revisit collective intelligence and its role in making the adaptive web a reality. Collective intelligence refers to the process of gathering insight from a group of like-minded individuals online, often implicitly, based on their shared navigation and engagement patterns. A central concept of collective intelligence is to aggregate behaviors of the silent majority of visitors across the spectrum of digital channels, augment that information with the expertise of super-users and provide the most relevant information that meets every individual user’s goals.

Not doing so will have profound implications for their organizations, most notably lost revenues and customer loyalty.

An obvious benefit to using collective intelligence is one of mere scale: it enables machines to draw conclusions about an individual's current intent based on the knowledge and experiences of the larger community. It also gives us the power to efficiently deliver automated and real-time experiences to users. This would be very difficult within any user-by-user scenario, which again poses enormous difficulties in matters of scale.

The CIO and CMO understand why their success depends on better IT/marketing alignment. Now, the challenge will be for them to deliver. While there’s no silver bullet, I believe collective intelligence has the potential to help them form a much more harmonious and strategic partnership. CIOs and CMOs must formulate their strategies for collective intelligence, context-aware computing and other technologies enabling the adaptive web right away.

Not doing so will have profound implications for their organizations, most notably lost revenues and customer loyalty.

This guest post comes courtesy of Dr. Scott Brave, co-founder and CTO of Baynote, a provider of digital marketing optimization solutions. He can be reached at brave@baynote.com.

You may also be interested in:

• Why HTML5 enables more businesses to deliver more apps to more mobile devices with greater ease
  
  
• Analysts define business value and imperatives for cloud-based B2B commerce
  
  
• Web data services -- here's why text-based content access and management plays crucial role in real-time BI

ThinPrint works to take cloud printing to mainstream

With companies putting more applications and data into Internet clouds, cloud printing is gaining momentum in the enterprise.

Vendors large and small are getting into the game. HP has made major announcements while Google has hinted at the future. Apple has begun services for iOS devices. Smaller companies like HubCast and ThinPrint have entered the fray. Yet, for all the attention, though, cloud printing is still not mainstream.

BriefingsDirect recently caught up with Thorsten Hesse, manager of Innovative Products for ThinPrint, to discuss the business drivers of cloud computing, the various options available, and the obstacles to wider-spread adoption of the technology.

BriefingsDirect: What are the business drivers of cloud printing adoption?

Hesse: In general, talking about printing is quite boring for most people. But people want to print. They need to print. They don’t want to talk about it, but they want to use it. They just want it to work.

Companies spend a lot of money for new printers, for printer management and print driver administration, for unused print outs, unnecessary paper and toner consumption, and for support and help desk. Printing is one of the most cost-intensive things in IT. Many companies also don’t want to be locked in with a specific vendor.

Increasing use

Another aspect is the increasing use of cloud applications and services. How do you print from cloud offerings like Salesforce or Google Apps? Mostly you create a PDF. Well, then you need a device that can print PDFs. Additionally, the use of smartphones, tablets, and other mobile devices becomes more and more common, and these devices can‘t do that, or only in limited quality.

Altogether, there are at least six business drivers for cloud printing:

• Printing is one of the most cost intensive IT services—and cloud printing can save cost and enhance productivity at the same time.
  
• Printing technology today depends highly on printer manufacturers.
  
• Companies want print on demand.
  
• Companies use cloud applications, very often unplanned.
  
• Employees are becoming increasingly mobile.
  
• Employees use new types of devices.

BriefingsDirect: What are the different options for cloud printing in terms of delivery?

Hesse: There’re three different delivery models. First, there is private cloud software. The first delivery model is that we sell software to our customers that they install in their environment, for example in their data center or on an Amazon server in the cloud.

This might sound far off, but as soon as customers manage their internal desktops from the cloud with Microsoft Intune, it will be a logical step to do the same with the printers.

They buy, own, and control the software. The other end of the spectrum is a pure cloud printing service. And then in the middle we've got the hybrid cloud, where some parts are run internally in the private cloud and others in the public cloud.

BriefingsDirect: Is cloud printing secure? What makes is it secure?

Hesse: First of all, the user can print content without needing to store it on the device, which brings all the advantages of central data storage -- secure and updated data in one place, no files lost when device is lost, and availability of service. The user can trigger the print job to the printer. He can also identify the printer.

BriefingsDirect: How is cloud printing evolving?

Hesse: Our solution is evolving in many directions. On top of offering print management as a software product that the customer can purchase and install internally, we’ll offer it as a cloud service. This will be a public cloud service. Customers can run it from the cloud. They can then control their internal printing environment from the cloud.

This might sound far off, but as soon as customers manage their internal desktops from the cloud with Microsoft Intune, it will be a logical step to do the same with the printers. This will evolve into a complete print management solution that can then be used not only to control the printing environment, but to build in policies to enhance it along the way.

BriefingsDirect: What is holding businesses back from adopting cloud printing?

Hesse: They mostly don’t know what’s possible, as the discussion is fogged by limited public cloud printing solutions.

BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached at http://www.linkedin.com/in/jleclaire and http://www.jenniferleclaire.com.

You may also be interested in:

• HP eyes automated apps development, 'standardized' private cloud creation with integrated CloudStart package
  
  
• Financial services firms look to cloud, grid, and cluster to allay fears over data explosion, says survey
  
  
• Cloud computing's ultimate value depends on open PaaS models to avoid applications and data lock-in

InfoBoom seeks US IT pros to take telephone survey, get stipend

The Infoboom, a site to which I regularly contribute for pay, is doing some research to learn more about how IT and business technology professionals meet their information needs.

The research involves a one-hour telephone interview and they are offering $100 American Express gift certificates to people who complete the survey.

Apply to be interviewed here.

You must be based in the U.S. and you must have significant involvement with business technology, but other than that they are pretty flexible.

This is not a marketing pitch and nobody's going to try to sell you anything. IBM, which underwrites the site, just really wants to know more about what its audience needs. Thanks!

How to automate ALM: Conclusions from new HP book on gaining improved business applications as a process

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

The latest BriefingsDirect podcast discussion examines a new book on application lifecycle management (ALM) best practices, one that offers new methods and insights for dramatic business services delivery improvement.

The topic of ALM will be a big one at next week's HP Software Universe conference in Barcelona. In anticipation, join us as we explore application lifecycle management (ALM) best practices for overall business services delivery improvement.

In this discussion, the last in a series of three, we underscore the conclusions from the forthcoming book and explain how organizations can begin now to change how they deliver and maintain applications in a fast-changing world.

Complexity, silos of technology and culture, and a shifting landscape of application delivery options have all conspired to reduce the effectiveness of traditional applications approaches. In the forthcoming book, called The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle, the authors evaluate the role and impact of automation and management over an application's lifecycle, as well as delve into the need to gain better control over applications through a holistic governance perspective.

In our first podcast, we focused on the role and impact of automation and management of applications, and emphasized the need to gain control over applications through a holistic lifecycle perspective.

The second discussion in the series looked at how an enterprise, Delta Air Lines, moved successfully to improve its applications’ quality, and gain the ability to deliver better business results from those applications.

Finally, we're here now with the book’s authors to explore their conclusions. Please join me in welcoming Mark Sarbiewski, Vice President of Marketing for HP Applications, and Brad Hipps, Senior Manager of Solution Marketing for HP Applications. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Sarbiewski: The life of an application is generally the same for all companies. There is a spark of an idea: "We need this. We need software to help us do something in the business."

We make an investment decision somehow. We may do this ad hoc. We may do it based on who screams the loudest. But somehow a decision gets made. We build something somehow. We spec it, build it, release it, run it, poorly or not, and hopefully, although certainly not always, eventually we replace it, retire it, and so forth.

We wanted to take a slightly different approach to how we thought about maturity models. There are lots of them in the industry, not so much around ALM, but in sub-disciplines or in different areas. Our focus was the business outcomes that you see at different levels.

We built out a model for ALM maturity, and it’s in the book.

... We see pressure from the business to change how we do things and the technologies we use. From the business side, you see it in a variety of ways. You see, "Oh, it’s the consumerization of IT, and what I see in my consumer world I want in IT. I see this all moving fast and I don’t feel my business moving." You see that pressure.

But, you absolutely see pressure to change from the bottom-up, from the teams themselves. We want to work in a different way. We want to be able to execute faster. The whole move of agile has been, in large part, if not primarily built, then driven from development and delivery teams up. So, there is a huge motivation there.

If you can understand the results that you are seeing, that ought to help you figure out where you could be. What we've seen is a progression from the spectrum of companies, ... [many] have fairly immature processes.

We see people just getting started, and they have a relatively ad hoc, narrow, point tool, with lots of manual work. It doesn’t mean they are never successful, but results vary highly. They're very mixed. Some project teams are great, and it all depends on the project team, and the next one may stink.

So our idea around maturity -- and tying it to outcomes -- is the results that we see. ... It all comes back to the results. What kind of results am I seeing? If you look at the model in the book, it’s pretty easy to peg yourself as to where you are and the kinds of benefits you'd see from moving up that maturity curve.

There’s a lot of pride when you see the metrics go in the right way. The feedback that I've seen for our clients that do this really well is where the business comes back and says, "Oh, my God. The responsiveness is incredible. Even if I'm not getting the massive stuff that I used to get once every two years, I'm seeing movement on a regular basis, and I love it." And lot of clients that we talk to are really fired up about that.

What we hear from our clients is that things are hyper-competitive and that technology, in particular software and applications, is a huge competitive advantage. So, our ability to move fast and beat the competitors to the punch with capability is enormously important.

More of a scorecard

Hipps: We configured this model trying deliberately not to be ultra-prescriptive. There are many heavy-duty models that do exist, and people can dig into those to their heart’s content. This is as much a maturity scorecard as anything.

One of the examples that you might see or one of the ways you might begin to engage yourself is something like defect leakage. Defect leakage refers to the number of defects that you discover in live in the application that you could have caught earlier.

We have some figures that show that the average is in the neighborhood of 40 percent of application defects that leak into production and are discovered in live. They could have been caught earlier. It may be little higher than 40 percent, which is a fairly shocking number.

But on the high end, the world-class customers we worked with, see less than 5 percent of defects working their way into production. So right off the bat there, you're talking an 80 percent-plus drop in the number of defects that you're experiencing in a live environment, with all the attendant cost savings, brand improvement, and good will in the business that you would expect.

That’s one example of the kind of thing that you can look at, tease out, and begin to get a sense of where might I sit maturity wise. From that, you can potentially take a cue as to where is it that I want to start, where is it that I want to make the biggest investment, as I look to make myself more mature.

There are hosts of sophisticated KPIs we can design for ourselves, but one of the key ones was, "I want to know what the business thinks of us, and whether we are trending in the right direction."

Speaking from the application domain, our friends in the agile communities have been the leading champions of this notion. Our default stand [as development teams] was one of being change-averse.

By that, I mean that there was this whole contractual relationship with business. You tell us what you need, and we're going to document it as best as we can, down to having all the semicolons in the right place.

"We're going to break out the quill pens and ink our signatures. Forever shall it be, and if you change anything here, we're going to hit you with the request for change, and it will go through a cycle of six weeks and maybe we'll agree to it," etc., etc. The longest time that was the mindset. You can look at that and say it's awful, but when I had far fewer applications, and they took far longer to build, it was just the way of the world.

The recognition today for all of the reasons we've talked about in this podcast and others, our applications are everywhere. They're always on. There is nothing I can do in a business that isn't going to touch the application. It fundamentally means, we need to sweep from the table, that notion of being change-averse. Instead, we need to be in a position of embracing change. We do need to be change-ready.

The leading traits

As Mark said, we need to be architected and engineered, from our people process technology perspective, to put ourselves in a position to be that way. In the book, we talk a bit about some of the principles we think come into play for change ready organizations. But, that's why it is one of the leading traits, the leading principles, in world-class organizations.

This could be a mantra of sorts: Think big, start small, scale quickly. The basic idea of think big is the idea that you want to spend some time making sure that you’ve all got a shared vision of where you want to be, and we talk a bit about whether that was a maturity model -- these principles of predictability and repeatability, etc.

Hopefully we've set at least some suggested guidelines for constructing what your end state might look like. But, this point about thinking big is that, as we all know, certainly in IT but probably anywhere, it's every easy to fall into a state of analysis paralysis. We've got to figure out exactly the right metrics to decide exactly what we're going to be. We've got to figure out precisely what our time-line is.

We sort of can borrow from our friends in agile, who have said that you've got to understand the perimeter of what it is you want to accomplish, but still it's bound to change. Those perimeters are bound to shift. You're bound to discover things about yourselves, your organizations, what's feasible, and what's not in the process of actually trying to get there.

It's important to set yourself an objective and make sure it's a shared objective. It's just as critical to get going to not fall into a trap of endless planning and reconsideration of plans.

So, it's important to set yourself an objective and make sure it's a shared objective. It's just as critical to get going to not fall into a trap of endless planning and reconsideration of plans.

If, you then pluck the low-hanging fruit, the easy things we could do starting this week, starting tomorrow, to advance us at least generally toward these ends, this end objective, that's great. Then, it becomes a matter of just continuing to move, scale, and adapt.

Somewhere, we make the point that, as an application team, certainly at least as an application member, I cared a lot more about measurable progress, seeing things actually advancing and getting better. Then, I cared less about how shiningly brilliant the end-state was going to be or exactly how we were going to get there.

Unconscious sabotage

Sarbiewski: I spent a number of years in a former life doing process change for companies. There were some trade secretes in the firm I worked with. They recognized some unchanging facts that that people can consciously or unconsciously sabotage the greatest plans, any process you want, or any kind of a change.

You have to start with people. It does involve all the people-process-technology in that order, but it's the people considerations. Do we have that shared vision? Who are the skeptics? Where do we think this could go wrong? Are we committed to getting there?

There were some questions we’d as we were embarking on making this change. First of all we said, what project or what pilot -- if we did these changes on it -- would people in the organization say, "If it works for that project, it will work for us as an organization."

So, find that visible pilot project, not one that’s an exception. Don’t find one where there are four developers and they are in the same room. If you try something new, people can say, "Well, of course, it worked for that, but that’s so atypical." So, find that project.

Beyond that, find the champion who is really respected in the organization, but skeptical of the change. We would go looking for one or two people who were open-minded enough to really give it a go, but maybe steeped in how we’ve done it, and have been very successful in how we’ve done it. Then, people can say, "That’s the kind of project we do, so you need to be able to make it work there. If Joe or Mary or whoever it is, if they buy into and it works for them, I believe."

The one other thing I’d say is start thinking about those types of metrics, those cross-silo and lifecycle-oriented goals and metrics.

Maybe, let's reward jointly the operations and the dev teams, if they’ve met those customer satisfaction goals, those service level agreements (SLAs), and those low counts of defects in production. You start to create a different dynamic, when you think more about lifecycle goals and cross-team goals.

Hipps: The spirit of this book, and probably the spirit of a lot of these kinds of books, ... If I have one hope, it’s that we haven’t been so pie-in-the-sky in our thinking that somebody reads this and says, "Yeah, nice idea, but it will never happen here."

So, that would be my hope -- somebody takes one single way that’s implementable in the near-term within their organization.

Sarbiewski: What I’m hoping is that in these hundred or so odd pages that executives in these enterprises that we're talking to have that opportunity to take just a couple hours and have somebody give them a chance to think about how important software is, and what the true life of an application is.

Once you start to go down that path and you start to say, wait a minute, 10, 15 years of evolving this capability, what does that mean? When things are live and I’ve got hot request from the business to make a change, what needs to happen? How much money will I spend on that?

The one "aha" moment is seeing that the 12 to 15 years matter, when I’m delivering value to the business and innovating for the business. In order to be successful during those 10 to 15 years, I will make different decisions when I build this thing. I will focus on a process.

I will build the automation to a different level, because I’ve stopped thinking that my job is done when I go live. If that’s truly the job, you’ll make a lot of shortcut decisions to get to go live. But, if you think bigger, you think about the full life of an application and what it delivers to the business.

All of a sudden, it makes a whole lot more sense to do things a bit differently, to set myself up for 10 years or 15 years of success with the business, as opposed to a moment when I can say, "Yup, I achieved a milestone."

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

Transcript of a sponsored BriefingsDirect podcast, the third in a series discussing a new book on ALM and it's goal of helping businesses become change ready. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• New Book Explores Automating the Managed Application Lifecycle to Accelerate Delivery of Business Applications

• Automating the managed application lifecycle helps Delta Airlines deliver better business results
  
  
• Dave Shirk on how HP's Instant-On Enterprise takes aim at new demands on businesses, governments
  
  
• HP Shows Benefits from Successful Application Consolidation With Own Massive Global Supply Chain Project

Automating the managed application lifecycle helps Delta Airlines better deliver critical business applications

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

The latest BriefingsDirect podcast discussion examines a new book on application lifecycle management (ALM) best practices, one that offers new methods and insights for dramatic business services delivery improvement.

The topic of ALM will be a big one at next week's HP Software Universe conference in Barcelona. In anticipation, join us as we explore a new book on application lifecycle management (ALM) best practices, one that offers some new methods for overall business services delivery improvement.

Complexity, silos of technology and culture, and a shifting landscape of application delivery options have all conspired to reduce the effectiveness of traditional applications approaches. In the forthcoming book, called The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle, the authors evaluate the role and impact of automation and management over an application's lifecycle, as well as delve into the need to gain better control over applications through a holistic governance perspective to help head-off poor applications productivity.

This is the second (read more about and access the first podcast) in the series of three podcasts on the "Application Lifecycle Management" book. We're here with the authors, but we are also here to learn about how one enterprise, Delta Air Lines, has moved successfully to improve its applications’ quality and impact and to better deliver real business results from those applications.

So please join me now welcoming our panel, David Moses, Quality Assurance Manager for Delta’s eCommerce IT Group, and John Bell, Senior Test Engineer in the eCommerce IT Group at Delta; book c0-author Mark Sarbiewski, Vice President of marketing for HP Applications, and c0-author Brad Hipps, Senior Manager for Solution Marketing at HP Applications. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Sarbiewski: The headline for me is that, more than ever, business moves as software moves; as your website moves, as your ERP system is advanced, your supply chain, and your financials.

Businesses are driven so much by software now that it's really the long pole in the tent. Standing up infrastructure is a necessity. Potentially, it can be done really fast. How quickly can I innovate on my capabilities for my customers or my internal users?

So, business moves as software moves. When we look at how we've done over the last 10 or 15 years, I could sum it by saying that legacy applications and approaches are just too slow. Not only are they too slow, they are too costly. They're riddled with security holes, which are increasing the challenges out there.

So, we have this dynamic that the business needs to move faster. Software is a prime driver in innovating for the business, and where we've been is simply too slow. We need to rethink our approach across the board, because there is no one silver bullet. It really boils down to I have to leverage the latest technologies for things like reuse, where I get huge leverage for richer customer experiences that need those wonderful new web application technologies that we have.

I have new processes that I can leverage in forms of agile and iterative types of things. To keep the cost in line. I really want to be able to leverage global teams for flexible low cost, but expert resources around the globe. I want them acting as if they were all local, like a dynamic Tiger Team that was all local.

That’s a lot of change to make happen to serve the ultimate business needs. We took the opportunity to take a step back and ask how all these things come together and how you can blend this modern approach to really deliver what you need to deliver for the business.

Hipps: This is a chance to take a step back and have a bit of brain space to consider and contemplate a lot of things Mark just touched on -- what are these ramifications for my organization?

Nine times out of 10, most of us who are in IT developing applications, trying to get on top of what it is the business wants, don't generally have the luxury of taking a step back and asking has the ground shifted underneath my feet with regard to all the things I am now expected to do and the ways I am expected to do them, whether that’s process shifts, organizational shifts, or technology shifts.

Generally the case is that the ground has shifted. Am I equipped, organized, and oriented to respond effectively to all these changes? That’s one of the driving factors of the book and one of the hopes that gives people a chance to step back, contemplate what these changes have been, and also give a bit of guidance about how we might better get on top of these changes and really wring the benefit out of them that we had expected when we first began to make them.

Innovating for customers

Moses: The biggest thing that we have at Delta is to make sure that we innovate for our customers and give them the latest greatest ability to take control of their situation. If somebody wants to book a flight, they should be able to do it on any media they like.

We want them to be able to make it in as few clicks as possible and as little typing as possible. We really want to make it as convenient for the customer and through the entire experience from the inspiration, all the way to when they are back home. We want to deliver quality products to them.

That comes down to innovation and speed, because you can innovate for ever and never actually release the product. For us, getting it out the door is very, very important. Some of the things that we've heard already from Mark and Brad touch on the need to back away, get out the weeds, and look at your overall lifecycle to make sure that you can get that speed. A lot of times, if you're doing the status quo over and over again, you never realize how fast you can be. So, you raise your head up, look around, and try to make some big changes.

Complexity is always the enemy of speed and innovation, isn’t it? The idea is to make it as simple as possible by having one version of the truth. You really have to get to that point, a central repository of data, a central tool that everyone can use. We use Quality Center. We keep everything in that, requirements, tough cases, automation. We pull scripts and things from there for our test plans. We have one area with all that data, so all of our areas can come to that and pull that information.

Whenever somebody needs to start up a script or anything like that, they’ve got a library that they can pull from. They can bring it into their project. When they are done with their manual testing and they place their test plan back in the library, they can then take those pieces and immediately automate them.

Somebody once said they required a form to find out who they were going to, or what pieces they were going to automate. For us, if you have one version of the truth, you know when things are checked back in. You know when your test plan has been updated and your automation people can make that decision. So, it's about getting rid of all the clutter, reducing the complexity, having simple processes, getting rid of all the ones that don't matter, and just really streamlining.

Recently, we've brought in some of the mobile devices like the iPhone and some of those types of applications. In the past, a large number of our customers have always been using the .com form. Now, we're finding more and more users are going towards the mobile devices.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

We wanted to make sure that a lot of the applications lifecycle testing we had done with the .com could also be used with the mobile. We were able to take automation and a lot of the test cases and type things we had used with .com and use it with mobile.

We did write automation associated with mobile and were also able to bring that back into Quality Center, running that via Quick Test Pro. Even though mobile was a newer area for us, we were able to get the speed to market up on that as soon as possible.

Also, we were able to leverage that and use some of those automated scripts. We run those on a daily basis against our production mobile environment. If something is wrong with that, we know early in the morning. We run these scripts early in the morning before we come in, and we can know right away if something is there.

They can go in and determine what new requirements they need to make and what enhancements they want. It's really helpful.

So we were able to take the lifecycle information and the wins that we have got from the .com, and bring that into our mobile apps, and it's really helped us a lot. Our speed to market has significantly improved with that.

Bell: Another case would be our new homepage. We're sitting here at the end of 2010. About two months ago, we released a new, more streamlined homepage, a lot more innovative. A lot of people looked at that. We hid the logo during usability testing, and people were surprised to find out it was an airline website. They thought of us as one of the cool guys out there in the travel world.

We're getting much better in this area. By using all the feedback that we get from the customers, importing information in the Quality Center, tracking everything that we have in there, we were able to look at what we needed to make changes to. Once we released this, it was something that the customers were wanting, so it got a lot of good response.

... One of the things that’s really important to us is that we work with multiple vendors in multiple locations and with multiple time zones. It's important to make sure that all of them are using the same processes and that we're all using the overall tools. We use quality center personally to help organize a lot of the requirements and things like that in our testing efforts.

It's important that all of our vendors, whether it's in-house or people outside, are giving us the same processes and that we are able to leverage any of our automation or any of our business process testing or any of those tools, and that we can actually deliver high quality software quickly, can reduce our turnaround time, make sure that we're giving customers their best experience, and that we are getting our time to market in a timely manner.

Moses: It's truly huge. I mean if you look at Delta.com, it's the main revenue driver for the entire company. So it's our face to the world, and streamlining that process where people are making it better and making the customer experience better is our number one goal. We want to really give our customers what they want and make it easy for them, because we have a wide range of customers.

We have pleasure customers who travel with their families once or may be twice a year, sometimes even less, and then we have people who travel with us every week. So we have two very different types of audiences and we have to cater to both. We have to make it fast and enjoyable and we have to allow them to dream a little bit and be inspired by where they want to go.

It's one of the biggest things that we have on our plate with mobile. Mobile is the future. Everyone is going toward mobile devices and portable devices. You're seeing more and more iPhones, iPads, and Android devices out there in the world, especially when you walk through the airport. We don't like that it happens, but sometimes things are out of our control like weather. And, we are always safe, so these things impact our schedule.

Core lifecycle

Hipps: In the book, when we talk about the core lifecycle, historically the SDLC -- we just call it the core lifecycle, so as not to get lost in alphabet soup. Within that we see traits among world-class organizations. There tend to be four traits that these world class organizations have mastered, and we list these traits as being change ready. They have a high degree of predictability, high degree of repeatability, and certainly their output is of high quality.

So those four: change readiness, predictability, repeatability and quality, tend to be abstracting some traits that we see across these great orgs. Those tend to be the key ones that really they are very effective at. David and John have talked about that we have got data points in each one of those, in some of the examples they have given.

A lot of this change readiness to a large degrees is formed by the point that we made in the beginning in the podcast, which is that fundamentally everything that business wants to do is going to have some applications or set of applications behind it. There is going to be a dependency there.

The business is only as nimble as its applications are. That puts applications teams in a position where they are not holding the business off at arms length, and saying, "No, no, no, no, no, I can't do that. No, that will take months." That rigidity may be historically where we came from, when we had fewer applications. They changed less. They were much bigger, more monolithic, and brittle. That is not the world we live in today.

Today, change is the expectation. David and John have been talking about this code being lead revenue generator and Delta.com being the lead source of revenue on the Delta side. It's a great example. Clearly, anything the business wants to do to advance its market presence is going to come through that application.

You’ve got to have that one version of the truth. I would highly recommend getting that, the central tool that everyone can use and that you can put everything in.

The fact that they have leveraged automation and asset reuse and taken the time to build requirements traceability are all tick marks you put against organizations that have configured themselves to be change ready. That means they have stripped out as much latency as possible, the time it takes to do impact analysis.

They can see pretty quickly what all the dependencies are as a new change comes across. That’s just speaking of the assessment. There is, of course, the execution, which depends on automation, asset reuse, and all the things they talked about. We probably covered four of those, but certainly the change readiness does stand out.

Moses: You have to have that one version of the truth. I would highly recommend getting that, the central tool that everyone can use and that you can put everything in.

Second, it’s about mindset and alignment to your goals. You have to have alignment to the customer. You still have to have department goals, but they should be aligned to what the customer needs.

Contradiction in goals

A lot of times, you see a contradiction in goals between the business group and an IT group. Delivering what the IT group wants to do may not exactly get what the business wants. And if the business was focused on the customer and the IT groups are focused on how many projects they can get out, but doesn’t really matter what projects they are, then there's an issue.

So, you have to really align very closely between business and IT, so much so that if you even have something that is a huge impact to your company, you may want to wrap a special forces team or integrity team around that, and have that group be one. Business and IT all in one group -- that way you completely eliminate the us-versus-them mentality. If you can’t do that, definitely make sure that you're aligned to the customer.

Bell: One thing to add to that is that, at first, it can be a little scary moving things in, like moving all your requirements into one area and getting all the test cases and things and even looking at automation.

Sometimes, you have to take a half step back in order to take a full step forward. With us, even as we were moving things and centralizing it, there could be a little pain point in doing that, but that pain point will more than payoff in the long run. A lot of the people who are holding on to the old methodologies and ways of doing business, are thinking, "We're going to have to take a step back to do this."

You're going to get that money back, plus your time, so quickly that you will be shocked.

Whatever step you take in that direction and whatever pain point you take as you move forward, once you start getting the automations in place, once you get these tools in place, you’ll see that you can start moving faster and faster that any initial pain point you took. You're going to exponentially get that money back, plus your time, so quickly that you will be shocked.

Just look at the changing world that we live in. With Delta.com now, we live here in Atlanta. If you go over to the airport, you realize that our business is not just flying customers within the United States in English. We now have kiosks in six different languages, and you meet people from all over the world that are now using our products and our websites in everything from simple Chinese to French.

It’s important that we realize the global nature of what we are doing, and that our methodology and our IT departments have to align ourselves, so that we can move this quickly. Without the automation and without the centralized tools and things we would never be able to put out as much work as we currently do.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

You may also be interested in:

• New Book Explores Automating the Managed Application Lifecycle to Accelerate Delivery of Business Applications
  
  
• Delta Air Lines improves customer self-service apps quickly using automated quality assurance tools strategically
  
  
• HP Shows Benefits from Successful Application Consolidation With Own Massive Global Supply Chain Project

New book explores automating the managed application lifecycle to accelerate delivery of business applications

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

The latest BriefingsDirect podcast discussion examines a new book on application lifecycle management (ALM) best practices, one that offers new methods and insights for dramatic business services delivery improvement.

The topic of ALM will be a big one at next week's HP Software Universe conference in Barcelona. In anticipation, join us as we explore the current state of applications in large organizations. Complexity, silos of technology and culture, and a shifting landscape of application delivery options have all conspired to reduce the effectiveness of traditional applications approaches.

In the forthcoming book, called The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle, the authors evaluate the role and impact of automation and management over an application's lifecycle, as well as delve into the need to gain better control over applications through a holistic governance perspective.

This is the first in a series of three podcasts with the authors the ALM book to learn why they wrote it and to explore their major findings. They are: Mark Sarbiewski, Vice President of Marketing for HP Applications, and Brad Hipps, Senior Manager of Solution Marketing for HP Applications. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Sarbiewski: In most large enterprises, applications have been built up over many, many years. You throw acquisitions into that and you end up with layers of applications, in a lot of which there is redundancy. You have this wide mix of technology, huge amounts of legacy, all built different ways, and the business just wants response faster, faster, and faster.

So, we have old technologies hampering us. We have an old approach that we've built that technology on, and the modern world is dramatically different in a whole host of ways. We're changing our process. We're changing the way our teams are structured to be much more global teams, outsourced, nearshore, far-shore, all of that stuff, and the technology is fundamentally shifting as well.

That's the context for why you see all these horror stories and these stats about the businesses' level of satisfaction with the responsiveness of IT, particularly in applications. If you think about it, that's what the business experience is.

... IT organizations are looking to change the game.

Hipps: A lot of these trends that we talk about -- outsourcing, service-based architectures, more flexible methodologies, whether it's iterative or agile -- you wouldn't necessary call any one of those brand new. Those things have been around for a few years now. Many enterprises we speak with and deal with have been leveraging them for a few years in some form or fashion.

If you're an owner of application teams or of a series of applications within an enterprise, these things tend to sneak in. ... You wake up one morning and realize all of a sudden that fundamentally the way your teams have long operated has been changed.

In some ways, it's death by a thousand cuts. No single one of these initiatives is going to force you to take a step back and say, hold the phone, let's figure out if the way we deliver applications now requires us to, in some significant way, rethink the mechanisms by which we conduct delivery.

From my own experience, it's difficult to get the time or the brain space to do that. Usually, you're neck deep in getting the next application out the door. You've got deadlines. You've got other applications or enhancements coming down the pike.

Necessary questions

You may not have the time to take a step back and say, "Wow, we're using these different methods" or "We're relying more on outsource teams, so we are not all colocated."

One of the objectives of this book was to do just that. Mark and I had the luxury to take a step back and think about what these trends mean soup-to-nuts for the way applications get stood up and delivered, and how -- from an enterprise perspective -- we have responded or not responded to those new complexities.

The nature of an application today is that it's not a monolith. It's not owned by a single project team or a program consisting of several teams.

Leveraging what we can

More often than not, it's something that has been assembled using a series of subcomponents, reusable services, or borrowed function points from other applications, etc. It's this thing that is, in the best sense, cobbled together. Rather than writing it all from scratch, we're leveraging what we can.

We can all agree that this makes sense, it’s the right way to do it, it's much more assembly line production versus handcrafting everything, which is certainly the direction we want to be headed in, from a software perspective.

But, that also presents us a lot of new challenges. How do I have visibility or discover the components that are out there, that are available for me to use? How do I trust that those components are reliable, that they are going to behave and perform in the way I want them to? Given the fact that I, as a given developer, didn't actually create it myself, how can I have faith in it? And, how are we going to authenticate all these different pieces.

It's not complexity plus complexity, it's more like complexity times complexity, when you consider modern delivery and its particulars.

?

So you've got these questions. How do we collaborate? How do we communicate? How do we notify each other of defects? How am I aware when something is ready to retest?

Relying on email is, let's just say, less than ideal. And, of course, we may be using different methods. Multiple teams could be using different methods. Those over there are working in agile fashion, we are working in waterfall fashion.

So the catchphrase we have, which may or may not make sense, it's not complexity plus complexity, it's more like complexity times complexity, when you consider modern delivery and its particulars.

Sarbiewski: The idea now is that you need both management and automation to achieve your end-goals.

People have long thought of those things in very narrow ways. They've thought of management of a narrow domain space, like managing requirements and automating GUI functional tests. Those were all good steps forward, important things, but there was little connection between management across the lifecycle and automation across the lifecycle.

You've got to think about both -- not only across the lifecycle, but how they interlock.

Part of what we're trying to get at here is this interplay. You've got to think about both -- not only across the lifecycle, but how they interlock -- to create the situation where I see what's happening. I see across these very complex endeavors that I'm undertaking, many people, many teams, many stakeholders, lots of projects, lots of interdependencies, so I have that visibility. When we need to step on the gas and go in a particular direction, and speed everything up without blowing everything up, that's when I can rely on nicely integrated automation.

Just about every square inch of the enterprise is automated in some way by software. What it has meant for IT teams is that you now have to understand every square inch of the business, and the businesses are incredibly dynamic. So any part that changes almost drags along, or in some cases, is led by, and has to be led by, innovation in the software to make that happen.

... You need to make software a core competency if you are going to differentiate your business going forward. So it's hugely important.

Hipps: Business can't twitch without requiring some change in a set of applications somewhere. ... We've got applications everywhere. They're going to be under constant review, modification, enhancement, addition, etc., and that's going to be a an endless stream.

We've got an expectation, given the web world we live in, that these applications, many of them anyway, are going to be always on, always available, always morphing to meet whatever the latest, greatest idea is, and we have got to run them accordingly.

We have got to make sure that once they are out there and available, they are responsive. We have got to make sure that the teams that own them in the data centers are aware of their behaviors, and aware of which of those behaviors are configurable, without even coming back to the application teams.

The legacy view said, "Wow, the software development lifecycle (SDLC) is the end-all, be-all. If I get the SDLC right, if I get requirements and deployment done right, I win." We realize that this is still critical. What we would describe as the core lifecycle is still where it all begins.

If I'm going to really be successful against what it is the business is after, I do have to account for this complete lifecycle? All the stuff that's happening before requirements, the portfolio investigation that's occurring, the architectural decisions I am making, have got to be true across the enterprise, as well of course as everything that happens once that thing goes live.

We've got an expectation, given the web world we live in, that these applications, many of them anyway, are going to be always on, always available, always morphing.

How well connected I am with my operation peers? Have I shared the right information? Have I shared test scripts where possible? Am I linked into service desk? Am I aware of issues, as they are arising, ideally before the business is hearing about it?

Those things are what we mean by getting your arms around the complete lifecycle is what's necessary, when you think about the modern delivery of applications.

Sarbiewski: Even in the requirements, there is an aspect that can be a level of automation and a level of management.

Automation can come in when I am building a visualization, a quick prototype, and there are some great solutions that have emerged into the market to help a non-technical user create a representation of an application that has almost the perfect look and feel. We're not talking about generating code. We're talking about using HTML and tools to create the flow, the screen views, and the data input of what an application is going to look like.

... Once we get to that look and feel of an app, at the push of a button, I can interpret all those business rules, all those rules about where was data, what was on the screen, was this data hidden, what was inputted, when did it flow to the next one, under what condition. All of that will get translated into a series of text-based requirements, test assets to test for that logic, and even the results and the rules and the data that needs to be input.

So, I have a process. I have had discussion and used some technology to visualize these requirements. At the push of a button, I automated the complete articulation, with perfect fidelity, including the positive test cases I want to run. I can manage those now, as I have always have, and my systems and teams expected to.

I now can push that information to each of the key stakeholders and automate the workflow behind that. This is what we mean when talk about changing the game.

Those requirements trigger test and defects and go against code, all of which can be linked. Whenever progress is made in any dimension against those requirements, I have created a test for one, I have run a test for one. I have run ten tests and eight paths. I have checked new coding against the bugs. All of that can be tied together and automated with workflow.

So, you start to see how I've got a creative series of information. I use automation to advance it to the next stage. I now can push that information to each of the key stakeholders and automate the workflow behind that.

This is what we mean when talk about changing the game and how you deliver software, by doing just that, thinking about, what are the things that I have to manage and how does automation speed things up, and create outputs with greater fidelity and greater speed.

Hipps: The endgame should be that what I've got is a unified way of getting these various operations connected, so that my management picture has a straight flow through from the automated things that its kicked off.

As those automated events occur, I'm getting a single, unified view of the results in my management view, which is, nine times out of 10, not the world we have when we look at big, big enterprise delivery. It is still a series of point tools, with maybe Excel laid over the top to try to unify it all.

... If you want to understand the future of IT, you just need to look at where manufacturing has come. We've plagiarized the lion’s share of what we do in IT and the way we work a lot from what we have seen in manufacturing and mechanical engineering. That extends to lean methods. It starts probably all the way back to waterfall.

Maybe it's no surprise that when you ask us to talk about what you mean by integrated management and automation, we are borrowing an analogy from the world of mechanical engineering. We're talking about what planes can do, what ships can do, and what cars can do. So, I hope this is very much a natural advancement.

Sarbiewski: I talk about the industrialization of IT. Sometimes, there's a little pushback on that, because it feels heavy. Then, I say, "Wait a minute. Think about how flexible Toyota or Boeing is." These companies have these very complex undertakings and yet can manage parts and supplies for providers and partners from every corner of the world, and every other car can be different coming off that assembly line. Look at how quickly they have shrunk their product lifecycles from design to a finished model.

Part of what's done that is exactly what Brad was talking about, an enormous investment in understanding the process and optimizing that, in supporting the various stakeholders, whether it's through design software, or automation on the factory line, all of that investment. We didn't do in IT. We built it ourselves. We used Excel and post-it notes and other things, and we created from scratch everything that we have done, because we can, because we made it easy to do that. We have made it easy to design and build it a thousand different ways.

There is this counterintuitive perception that because there is an infinite number of ways, we hold ourselves to be different than that. People are realizing that's not really the case. In fact, the more I can industrialize and keep it lean and agile, how I do this, the tools I use, if I give the people incredible tools to do it, and not just point tools but integrated, the results really speak for themselves.

They have essentially industrialized their approach, they have integrated their approach, they support their stakeholders with great technology, and they adopt to change their process.

When we talk to customers that have done this, they achieve incredible results in three critical dimensions. There's a very longstanding joke that you can't go faster, you can't raise quality and take cost down. It's not just possible. This is this impenetrable triangle or it’s squeezing a balloon. We see with our customers that you absolutely can.

They have essentially industrialized their approach, they have integrated their approach, they support their stakeholders with great technology, and they adopt to change their process. Guess what, they go faster, they take cost down, they drive quality up.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

You may also be interested in:

• Doing Nothing Can Be Costliest IT Course When Legacy Systems and Applications are Involved
  
  
• Shoemaker on How HP CSA Aids Total Visibility into Services Management Lifecycle for Cloud Computing
  
  
• HP Advises Strategic View of Virtualization So Enterprises Can Dramatically Cut Costs, Gain Efficiency, and Usher in Cloud Benefits