Most large corporations attempt shared services out of necessity and common sense. After all, duplication is wasteful, and sharing services for application hosting and administration promises to reduce cost, complexity and waste. But while I’ve seen it succeed, more often than not it’s a struggle to satisfy all of your development groups without requiring too many exceptions to the development and deployment process — and that offsets some of the gains.

To get another view on the subject, I recently interviewed several IT executives, including one at a major financial institution, about their efforts with shared services. Not only is it possible to succeed, this executive said, but “We are doing it.” The biggest challenge he found “is supporting a robust technology stack without turning off projects” that are not on the list of common platforms. For example, the company has promoted shared platforms in four categories: Java, .NET, databases and general Unix deployments. The Java Application Platform was the first, and it has been in production for more than 10 years. “This is a shared services platform based on WebLogic server, Solaris (changing to Linux), and a popular tools stack. The servers are large core machines,” he explained, and developers must use the specified environments. If you turn off projects, you may fact downtime or poor service.

Getting everyone’s buy-in, therefore, is critical when moving from dedicated to shared applications. The first challenge is getting your development teams on board and willing to integrate their development cycle with the requirements of a shared services platform.

CIOs are often concerned that development teams will push to do what they please, despite the best efforts to build a common platform Another IT executive, who did not want to be identified, said that satisfying each development area is critical to adoption, but it is also important to tighten the reins to a degree. “If we were to support an ad hoc technology stack, it would not be feasible to perform proper testing, diagnose problems and provide support.”

Striking a Balance

The key is to strike a balance between meeting everyone's needs with a single platform and not requiring too many exceptions to the development and deployment process. A joint effort is needed. “To promote consensus, we form technical advisory groups (TAGs) comprising representatives of all areas of the bank, [who] agree on a technology stack,” said the financial services IT executive. “Once that’s decided, teams have to make a strong case to introduce competing technologies. If you need a technology that is not supported, you will generally be granted an exception — but a TAG will first review it and make a recommendation, he said.

Focusing on developers is only part of the story. Additionally, “maintenance of the technology stack is in the hands of the operations teams,” and end-of-life migrations can be hastened as part of their job. That’s an important point, since a common complaint is that shared services platforms tend to stagnate in terms of technology. According to the financial services IT executive, “We use a three-year strategy, and every year a new platform version is released. Applications on the previous release are notified that they will need to migrate within the year.”

Cloud-based Solutions

Building on standards-based systems has become more critical as enterprises explore the cloud and Platform-as-a-Service (PaaS) solutions, but views differ about which approach to take. “In a financial services firm, it’s difficult to get any traction on an external platform. However, a hybrid strategy is practical,” so you can “host non-sensitive data and applications on external clouds while keeping the rest more securely in-house”, the financial services executive said.

In my own experience, even if you never deploy to a public cloud, there’s still something to learn from them. The financial services IT executive I spoke with agreed: “We can learn from the cloud vendors about automated procurement, security and monitoring, and then build internal clouds based on industry experience.”

Overall, it is possible to build out shared services in the enterprise and reap the benefits. However, you need to have a close working relationship with each development group to understand its unique challenges. Here’s an example an IT executive presented: “Low latency applications have a special challenge. If every machine instruction is critical and a poorly timed, garbage collection can be expensive, some teams are understandably reluctant to run on shared hardware. But others take a more practical view and ask the operations teams to guaranty their Service Level Agreements.”

The key takeaway is that building a single shared services layer shouldn’t be a quest for a single holy grail, or a mandate from an architecture group. It needs to be a corporate-wide team effort where all stakeholders are involved, including the CIO, the enterprise architects, and the development and operations teams.

Stakeholders may question whether this centralization really benefits the business or affects business users in any way. “Actually, the goal is the opposite,” said the financial IT executive “[We aim] to tighten up the plumbing without impacting the business.” And since the cost savings are significant and the financial industry is operating under so many new legislative constraints, the push will continue. “The savings are integral to success.” It’s hard to question that.

Eric Bruno is Principal and Technology Specialist at Allure Technology Inc., where he is focused on software design and applications.

When I talk to people about Agile marketing, many think it‘s a new concept and that agile methodologies from the IT world are not easily translated to marketing.  My experience tells me agile marketing is, in many cases, simply the formalization of what great marketers have been doing for years: following basic business practices and project management. 

Agile, at its core, is pragmatic and focused around prioritizing what’s most important to your company’s strategy with the people most impacted by the work. What I didn’t say, was that agile was easy to get started with, although it certainly makes execution easier once you have your team and priorities in order. Aligning priorities and getting the right people at the table to do that prioritization are central to doing agile the right way-- whether you are talking about an IT project or a marketing program. Agile Marketing is also about being adaptable in your marketing programs.

Aligning priorities and getting the right people to the table are central to successful Agile Marketing. To that end, here are 10 things you need to do to create an agile marketing organization:

1. Be ready to empower your teams to take responsibility for delivering their programs within budget and a fixed timeframe.
2. Hire and grow highly adaptable people. I'm sure many of you have heard the quote most often attributed to Charles Darwin: ”It is not the strongest of the species that survives, nor the most intelligent of the species that survives. It is the one that is the most adaptable to change."  Agile marketing is all about adaptability to market change. I discuss in my book Agile Marketing, that  this practice can be nearly impossible to execute in the business world unless you have individuals who are innately adaptable.
3. Create program teams that are cross-departmental and include both your end customer and people from all across your internal value chain to develop your programs. Don’t work in a marketing silo; include all those in the prioritization and planning process. Think end customer, sales, legal, as well as IT, to help you in developing out your program.
4. Set priorities that are focused on what gives the end user and business the most value and what is easiest to accomplish. 
5. Let your marketing team play ‘planning poker’ to estimate what is easiest to accomplish. 
6. Give your team a fixed time period to develop the first set of priorities for the marketing program and work in one month sprints, testing your work on your end users along the way to know what is best to iterate on in later sprints.
7. Have daily scrum calls where your marketing program developers focus only on those things they have accomplished and what they have next to accomplish as well as any obstacles they need to get out of the way.  Don’t let others outside the agile process get in the way of this conversation, they can listen, but only allow those who are accountable for delivering something the ability to talk on these calls.
8. Set up weekly project leadership team calls that allow executive leaders and other constituents an opportunity to see progress and where there are challenges and give them opportunities to provide direction. It’s important, however, that any new program requirements be put in the program backlog and not upset priorities mid sprint.
9. Create and manage an active marketing program backlog of the changes people suggest. Manage the prioritization of them monthly using the estimation process in points 4 and 5.
10. Iterate to success…..just like your IT projects, everything, including marketing, can be improved by working iteratively with a collaborative, customer-focused team.

For more about Agile trends, read Dion Healthcliffe's blog on Smart Enterprise Exchange here.

And Smart Enterprise Exchange members can learn more about Agile Marketing by downloading Chapter One of my book.

Although “align IT to the business” is one of my most un-favorite buzz phrases, it never the less is critical for IT organizations to do. I’ve been a part of more and more discussions with organizations who are focused on driving business goals rather than technology ones. As IT organizations focus on agility and cost I often think about the reasons why some organizations are slow or outright unwilling to move towards business alignment. Here are five hopefully humorous excuses for not aligning to the business. After all it’s now early January  and digging deep into a heavy IT blog is not on the top of your resolutions. So enjoy what I hope is some minor comic relief during the beginning of the year craziness.

In David Letterman-esque style.

1. Priorities- it’s up next after our Windows 7 migration and our Exchange 2010 upgrade.
2. Our executives have iPads now. Doesn’t that mean we are aligned?
3. I’m waiting for the cloud to do it
4. ITIL doesn’t have a book titled “Align IT to the business”. But when it does I’ll be sure to send my team to a certification class.
5. My successor will do it

The #1 response is what all CIO’s should be thinking. If they do not provide financial transparency and proof that they are helping drive the business, then the organization will find someone who will.

Happy New Year!

As noted in my previous blog, Social Business and Agile Methods: A Perfect Match. Part 1, I firmly believe that cross-pollination between agile methodology and social business is needed to shorten project schedules, access wider pools of innovation and deliver on the promise of business agility.

Below is an attempt at formulating just such a merger.

Some agile process purists are still on the fence about applying their methods more broadly to other fields. But in my experience as a business-transformation practitioner, I find that agile methods are quite applicable to many creative activities involving teams of people. That’s why the focus described below can apply to general-purpose business processes of any kind instead of specific types of people-based activities, such as software development. Some processes are more amenable to agility than others, just as some are easier to transform with social business.

The general rule is that the less collaborative, less changeable and more user-isolated a business activity inherently is, the less applicable either agile or social business methods will be to it. Conversely, most complex, open-ended and outcome-oriented business processes involving groups of people working in tandem — such as knowledge work in finance, science, engineering and medicine — can be better addressed with both agile and social methods working in tandem. If that's so, it makes sense to integrate them better, rather than applying them separately to the same business activity.

The points below show how agility and social business compare, contrast and support each other:

• Coordination Instead of Control. Agility and social business methods both avoid using centralized hierarchies to achieve deterministic control. In lieu of this, as leading agilist Brad Appleton has observed, they both work best with autonomous, adaptive and accountable actors. The first two aspects — autonomous and adaptive — apply equally well to social business, while the latter (accountability) is a natural part of any social environment that has user identity. The key point is that emergence — a unique and prized aspect of enterprise social media — and self-organization are very similar and are core values in each discipline.
• Design for Change/Loss of Control. Agile and social approaches both work best in an environment of controlled chaos. Encouraging emergence, and ensuring that it's not accidentally prevented, requires accepting that external change is desired. Emergence should be responded to productively to get the right results with the resources at hand. For example, ignoring that customers need requirements, that the planned outcome of a collaborative process won’t provide the expected benefits, and otherwise denying reality are anathema to both disciplines.
  

It is true that the profound reverence for steering processes from ground truth (and hard data) is usually better defined in agile methods. Social business methods like crowdsourcing and social collaboration recognize that most productive output is on the edge of the network and largely outside of formal control. But measuring community sentiment is often as far as it goes in terms of responding to change — although informally the community changes the direction of the process all the time.

As a result of these traits, the best results in both approaches come when there are tight feedback loops to all stakeholders and when a planned response to that feedback is the central factor in re-engagement with the project or online community in the next cycle. For more details, read Tim Leberecht’s insightful overview of this issue: Openness or How Do You Design for the Loss of Control.

• Rapid Work Cycles. Agile methods call work cycles "iterations." Social business doesn’t have as strong a notion of discrete work cycles because it’s essentially continuous and is itself emergent. In essence, it's a more extreme version of iterations, at least when you look at collaborative work in social media environments such as crowdsourcing efforts or social CRM. Either way, the project and/or community assesses and responds to change at the end of each iteration, or does it almost continuously, as in the case of social business processes.
• Open Participation. The best results of social business are when the broadest possible net is cast for stakeholders to connect to the project or process and then contribute. Agile processes confine valid contributors to a much narrower, more well-defined audience, though open participation is entirely up to the project and does happen. Social business advocates that “anyone can contribute” — one of the most powerful concepts in recent business history. Only those who care about the outcome will get involved, yet that’s almost always more people than traditionally expected. Social business actively encourages and is very good at driving mass collaboration. Agile methods could learn from social media’s extreme openness and its lower contribution barriers.
• Working Results. Agile processes value a working outcome as often as possible at any given time in the project. When the requirements are right and/or the budget runs out, stakeholders have any output possible at that point and it's in early working order. Social business is not yet so disciplined in its directed outcomes, yet by its very nature is always up to date with the latest revisions, contributions or updates.
• Continuous Processes. While agile processes use frequent iterations, milestones, review steps and other processes to make rapid course corrections (typically every few days or weeks at most), social business is at an even higher velocity and larger scale. Consider real-time processes that run around the clock globally involving tens of thousands and sometimes a million or more simultaneous contributors. And think open source projects, which actually do this for software development. This means the scale and velocity of social business often outpaces agile by several orders of magnitude — a very surprising difference, given that agile is already quite a bit faster than traditional methods. For its part, social business could learn a lot about continuity (builds, releases, work product iterations, etc.), while agile can learn to scale and accelerate outcomes in a way it never could before.

While this breakdown is a good beginning, it's only an initial attempt to connect these two closely related fields. I'm hoping to start a useful discussion, and I'd love to hear your thoughts about where there might be nuances to change or details to be tweaked. Add your comments or contact me on Smart Enterprise Exchange.

To the cloud we go. At Nemertes Research, we just completed our 2011 enterprise IT benchmark study, and we find very high interest in private clouds. In fact, 35 percent of the 240 organizations participating in the benchmark will have a private cloud within the next two years.

Nevertheless, as businesses embark on the road to virtualization and cloud environments, an unexpected speed bump is appearing: the issue of self-provisioning.

When analysts talk about private clouds, we assume everyone is on the same page: A cloud is a metered, multitenant, accessible, elastic and self-provisioned service offering. Right? Well, maybe. Most enterprise IT professionals agree with these characteristics, though many say they have a private cloud even without some of these fundamentals. The factor that they most resist is automated self-provisioning.

Despite the fact that most respondents with private clouds indicate they will eventually offer self-provisioning, some pushback remains. Why? The biggest reason expressed by nearly half (48.5%) of organizations is sprawl — or the self-provisioning of virtual machines and storage that never spin down, even long after they are no longer in use.

Sprawling Concerns

The positive side of sprawl is that it demonstrates the ease with which system operators can allocate servers and storage in seconds with just a few mouse clicks. It’s also the bane of many a virtual infrastructure because it eats storage and CPU resources and ties up network resources; basically dead weight. “Our challenge is managing waste and service sprawl. It's tough enough when you have a highly skilled team managing it today,” says the CIO of a small publishing organization. But he fears that moving to a self-service portal environment "will make sprawl management really tough. Blowing through 200 terabytes in the first week would be a problem.”

What it comes down to for many operations staff is balancing full automation with human involvement to better manage sprawl and retain good processes. It occurs to me that the arguments against cloud provisioning could be just another example — like social media and consumer technologies — of IT having trouble giving up control of business services. Perhaps there are some similarities, but I believe that cloud self-provisioning concerns can be easily addressed with better collaboration and governance.

System operators who want to remain in the workflow aren’t only protecting their egos; the reality is that IT is ultimately responsible for the infrastructure, which IT’s customers — both development teams and business units — are provisioning. Some IT professionals are very concerned about unnecessary self-provisioned systems that may boost costs and waste resources (more justification for charge-back, however). For others, it’s simpler: “dealing with insufficient competence on staff outside of IT,” says the CTO of a state government organization . And, for still others it is the legitimate concern of losing touch with the customer.

Governance, Processes Needed

What’s really critical, therefore, are proper policies and procedures for managing the costs associated with self-provisioning. In organizations where business units have development teams, there’s already a process for requesting compute and associated storage resources. There’s no reason that once self-provisioning is implemented, governance should go missing. “We want to do it more generally, but we have to have rational constraints, some kind of background business processes,” says the CTO of a large higher education institution about self-provisioning options.

Ultimately, it’s important to separate the technology of self-provisioning from the process of self-provisioning. Self-service portals, tools and service catalogs are available today. Needed now are processes and procedures that deal with self-provisioning to make it effective, efficient and flexible enough for both IT and the business units to meet customer needs. That’s when the speed bump will no longer prevent a smooth ride to the cloud.

Share you experiences with me and your peers. Add a comment.

Thanks to fast moving technology companies like Apple and Google the IT world is now obsessed with innovation. Not to say innovation has been unimportant in the past, but it's now a close second in the techie buzz word dictionary only to "cloud." However, it's hard to say "innovate" without giving employees at least the right environment to do so. After doing some reading on the topic I thought I would share my thoughts on ways to get your IT organization to at least start sharing ideas that could form a good foundation for innovation.

First I highly recommend watching Steven Johnson's amazing TED talk on innovation titled "Where good ideas come from." He tells a humorous and thought provoking story on how ideas can connect, mature and eventually flourish. If you find the talk interesting then go out and buy his book of the same name (or you can watch this 4 minute video overview of the book). The book covers in much greater detail what types of environments help foster innovation.

Openness serves ideas better than walls - This is often a tough one in traditional IT departments. There is a strong belief that the thoughts and ideas in your head (tacit knowledge) are your intellectual property and by keeping it to yourself you stand to gain more by sharing it. This is the classic job protectionist line of thinking. But when it comes to innovation it just doesn't have the same rate of success as sharing ideas and being open. A team that openly shares their ideas is a team that will be more successful. Ultimately ideas that work are often ones that connected with other ideas.

Ideas are hungry for other ideas - As said above many individuals' ideas aren't fully formed and they need to connect and be discussed to become a reality. Johnson likes to use the coffee house as an environment that generates informal discussion. It's a comfortable environment where people can talk freely and allow their thoughts to connect and form new ideas. Try to create an environment during team meetings that promotes free form discussion where you don't have the formal organizational structures (i.e. judgment and hierarchy). This could be literally going to a coffee house, a team lunch outside the office or a walk around the office park.

Follow the improv rule of "yes and" - If you know anything about improvisational comedy then you are well aware of the most important rule "yes and". Meaning you don't disagree with your fellow actor but rather agree and add onto that thought and push the scene/plot further. This is a great rule to follow in a team meeting by taking a suggestion or idea and pushing it further. It also promotes openness.

Put all your junk on the table - In Johnson's book he talks about the movie Apollo 13 and how the team on the ground that is trying to save the astronauts puts all their spare parts on a table and are told "figure it out." Put all your components, systems and processes on the conference room table (figuratively that is) and think about where they either work well together today or are disconnected. What are the biggest problems for the business or IT right now? Can these parts be put together in a different way to solve it? Do we need all these parts?

Are there leftovers? Can we make a soup? - My grandmother could always make a great soup out of last night's leftovers and available items in the kitchen. Like soup, some of the most amazing innovations have come from what many see as junk or waste from an existing product or process. From an IT perspective what waste or noise do your applications or processes generate that could be used in other processes or applications? Is there gold stored in those log files or data exports that we could use if we mine it?

Innovation in IT is often about automation - The low hanging fruit for innovation in an IT organization is usually automation. It could be automating a manual process, or even getting rid of an expensive or unnecessary process. Don't feel that innovation can only be achieved by buying a new piece of technology. Instead look at ways to get rid of technology that isn't adding value or could be slowing your team down.

Do your business group managers praise your cost-cutting abilities? Does top management say that for the first time they "can see what is being delivered by the IT" side of the business?

Volvo Group CIO, Magnus Carlander, can make these claims. He uses his dual roles-- as CIO and also as CEO of Volvo IT-- to deliver high business value at low cost and it's paying off for the Sweden-based automaker. Whether he's automating a logistics process or implementing a global videoconferencing system, Carlander tells Smart Enterprise magazine's Executive Editor, Karen Bannan, that he is acutely aware of customer needs, costs and overal business goals to guide his technology decisions. Other tactics include standardization across factory production lines, hardware consolidation and better use of business intelligence tools.

Sound good? Read the full article in the new issue of Smart Enterprise magazine here.

There's a new data center in town. What's new about it? The cloud, mainly. But also virtualization and a new reconsideration of the mainframe. For many CIOs, the changes couldn't come at a better time...as an article in the latest issue of Smart Enterprise magazine, just out, explains. To learn all about it, check out the new article, The Greater Data Center.