Jarrett House North

Charles Giancarlo and Steve Mills are on a panel with two Gartner officers. Giancarlo defines “complexity” as anything that causes customers headaches in implementation. Customers want simplicity, by which they mean that solutions are thoroughly tested for their environment, not fewer features. He points out that we simplify the mundane (networking protocols) and then build greater complexity atop the newly simplified stack. He also correctly points out that the desire for differentiation is a big source of complexity.

Mills says that complexity in software is a reflection of the desire for more autonomy from central IT control, and stems in some respect from the decentralization of IT infrastructure starting with the shift to minicomputers in the 1970s. He also says that software will continue to get more complex: “software developers, given enough resources in time, will reinvent the work of everyone who’s come before them.” He suggests that encouraging reuse and adoption of open source can help to simplify the stack by not encouraging the development of new code, and that bloat is primarily caused by a cultural issue among software programmers. Giancarlo agrees: if improvement in software code doesn’t directly drive customer benefit, then it isn’t worth doing.

Mills says that defeating the developer’s cultural tendency toward re-creating the wheel requires: time-boxing, or defining short-term incremental projects; starving the team for resources; and embracing user-centered design.

(My battery is dying; more to come.)

Later: In discussing how to improve reliability in the face of proliferating software versions, Mills talked about reducing redundancy in code and reproducing known configurations and feature paths in the test environment. Giancarlo talked about lessons learned from integrating Linksys’s consumer business in creating a balance between complexity and functionality.

Causes: infrastructure is cumulative (earlier today someone said applications never die; the consensus appears to be that retiring outdated IT offerings is almost impossible). One thing that might help is, following Drucker, to continue to push good ideas down into silicon so that they move lower in the stack. Unfortunately, says Giancarlo, complexity grows organically: today’s skunkworks project is tomorrow’s killer competitive advantage, so it adds to the complexity. The wrong thing to do is to try to remove complexity from new products; rather, look at them when they provide comparatively less value and try to remove complexity then. Also, the multiplicity of architectures can be a political issue.

Why to reduce complexity through SOA: Mills: money is lost in the cracks between all the handoffs between different legacy systems. You need to add some IT complexity in end-to-end monitoring to enable the business to reclaim the money lost in its patchwork of pre-SOA systems. Governance is one of the most important solutions for reducing complexity.

One thing I find interesting is the small number of bloggers in attendance at the conference. I’m currently sitting next to the only other blogger on the conference blogroll, Boris Pevzner of Centrata (and of MIT Course 6 mid-90s). Feedster and Technorati don’t turn up many hits for ITxpo; in fact, Feedster notes that this site is the biggest contributor and helpfully offers to scope the search relative to this site, which is a little scary. Likewise, most of the hits in Technorati are follow-ups to press releases or announcements made at the symposium. Is there so little of value that happens at the ITxpo that no one has thought to do it before, or is it just that the sort of organizations that have embraced blogging are under-represented among the attendees?

Certainly the logistics have a way to go before the conference becomes truly blog-friendly, with none of the socratic dialog (or good WiFi) that characterize the best of the unconferences I’ve attended. But the presence of the conference blog is a nice first step.

Ken McGee is speaking about real time enterprises. He claims that with real time enterprises, which represents IT moving beyond its traditional boundaries into adding real value through real time monitoring and modeling of events in the company, that business uncertainty becomes “unnecessary and unavoidable.” The talk is an expansion on Ken’s book, Heads Up. The idea is to monitor, capture, and analyze root causes and overt events and use them to make near real time decisions.

One way to leverage the benefits of real time decision making, McGee suggests, is to publish financial information more frequently, which not only mitigates compliance risks (a la Sarbanes Oxley) but also has the side benefit of attracting investors eager to get more frequently updated information about the performance of their portfolio. Another is to investigate dynamic pricing. Both of these are predicated on taking known IT capabilities to the next level. In the case of dynamic pricing, this includes supply chain management, sales, electronic ink (for retail price display), wireless, and future demand prediction.

McGee also discusses decision criteria for what should be monitored in real time: only choose the information that, upon receiving it, would make a decision maker change her course of action (this does not include most “dashboard” information), and where such a decision would have a positive effect on the top ten revenue-generating (or cost) business processes. This turns out to yield a very small number of real time factors.

But he also says that IT people are going to be the most likely to block real time data gathering efforts. He doesn’t dive into this deeply enough, in my opinion. This is the area that might really yield some insight into the dynamic between decision making and IT.

This morning’s first session for me, Excellence in IT Service and Support, was a review of best practices in service desk management. A few interesting data points came out in the context of the talk, including informal survey results (of Gartner Data Center conference attendees) indicating that about 62% of respondents intend to adopt ITIL, either alone or with other methodologies; the number for ITIL alone was 31%.

This was interesting to me because the further in ITIL one gets away from service desk and incident and problem management processes, the more the coverage of the standard starts to overlap with other well-defined process libraries. For instance, processes in ITIL, including release management and change management, dealing with internally developed applications have a natural overlap with the Capability Maturity Model Integration (CMMI), which has software development as its focus. Organizations with internally developed applications need to consider not only which portions of ITIL, but also which portions of other methodologies, they may need to adopt as they carry out process improvements.

Some follow up links on IBM/Tivoli’s ITSM announcements yesterday.

CNET: IBM’s Tivoli tackles IT processes: “The majority of application failures are due to changes that get introduced to a working system, said Bob Madey, vice president of strategy and business development for Tivoli.”

ComputerWorld: IBM unveils Tivoli systems management software. “The idea of having a centralized database for tracking IT assets in an organization arises from long-standing recommendations by the Information Technology Infrastructure Library (ITIL) and other systems management groups. BMC has already announced a centralized database, but IBM believes a federated approach makes more sense because many companies have infrastructure databases already, Madey said.”

The MarketWire release talks about the expansion of IBM’s Open Process Automation Library aka Orchestration and Provisioning Automation Library(OPAL) to IT service management, a point I failed to capture yesterday because I need to know more about it before I fully understand the implications.

Well, that’s it for my first day at ITxpo. I’m off to Toronado.

Hey, a quick thought to other bloggers at the conference: while Gartner is mediating a networking breakfast on blogging on Thursday, I’ll be heading out on Wednesday night. If you’re interested in having an impromptu blogging meet-up on Tuesday or Wednesday—in or out of the scope of the conference—ping me.

After the posting flurry of the morning, my battery (laptop and biological—damned jet lag) ran out, so I caught a nap before heading back to the Moscone for the afternoon sessions and the opening of the ITxpo floor. The sessions that I attended after the IBM presentation were complementary, so I’m going to wrap my notes up in one post.

The session on ITSM and IT Operations was a good overview, discussing the IT Management Process Maturity Model (an IT-centric take on the CMM), with an emphasis on building the service portfolio and treating it as a marketing document. The session on Configuration Management focused on tools that map dependencies between assets (hardware, networking, software and software components); this sort of approach is required if you are to provide effective support for an end-to-end service in the enterprise.

Both sessions had a fairly grim assessment of the move toward service-oriented IT service management. The ITSM session stated that through 2008, 65% of organizations will be focused on non-service-focus metrics like availability of individual servers, rather than end to end availability; and that it would take about five years for application development to start mapping service dependencies as part of the development process. Both sessions agreed that at least for the next year to 18 months, configuration management was going to be a largely manual activity.

It seems, with the proliferation of tools that provide configuration management for some piece of the IT puzzle, that the opportunity is for someone to provide a general standards-based interface to span across multiple CMDBs and to create connections and integrate key ITIL processes, particularly change management. But the cost could be dear: Ray Paquet estimates that, depending on the scope of your configuration tracking, you could have as many as 100,000 assets in a moderate-sized organization, and that the number of relationships that could be tracked scales exponentially. The challenge is to provide intelligent oversight across these databases but to provide drillthrough where required so one solution isn’t holding all the data.

IBM unveils a stack of IT Service Management products, including new products and fourteen enhanced products. Key is an open federated configuration management database. Positioning as helping provide tools and practices to make ITIL more implementable. More coming…

IBM says that they’re uniquely positioned to bridge development and infrastructure, between Rational and Tivoli. This positions them to help make IT services more manageable.

Organizations have choices: implement lots of point solutions to fix specific problems, adding complexity; outsource, possibly losing a competitive strength; or apply ITSM. Customer testimonial from Patty Medhurst at Royal Bank of Canada. Complex environment, automated testing, etc. First step to ITIL is documenting the service catalog, which is a “gruesome but necessary” process; next step is automating key services.

Steve McMillan, leader of IBM Integrated Technology Services: moving from resource management to systems management to services management. In services management, need models: business reference model, process reference model for IT, and implementation reference model for IT. Business reference model: uses Component Business Model from PwC; move those into IT Process Reference Models and then into a Unified Process Model. (Aside: So far this is about architecture and modeling, not management…)

Customer testimonial 2: Don Woodward, American Express. He talks about using simulation tools (WebSphere Integrator) to build a simulation of the end to end infrastructure and to model the effects of process improvement on cycle time.

Now, focus on change management. Existing products fit in different steps. Now the new IBM Change and Configuration Management Database (CCMDB) maps changes in relationships and business data, plus policy and workflow actions. IBM IT Service Management: new platform in IBM Tivoli CCMDB. IT Process Managers: workflow capability, customize workflow, enable application of IBM/Tivoli technology to each step of process. Plus of course services.

IBM Tivoli Unified Process: process reference model for IT, aligned with ITIL. “Customers don’t have the sophistication or capability to map their processes, so here’s this online tool to help you do that…” And OPAL: expanding to auto-discovery. The process modeler is graphical, providing detailed workflow and activities for each step.

Other points: enhancing Tivoli Configuration Manager and Provisioning Manager with patch management and autodiscovery; new Federated Identity Manager, enabling extension of Tivoli Identity Manager out across the supply chain and to customers.

(Incidentally, here’s the press release—took quite a few clicks to find it.)

The CCMDB: Integrates supporting products and higher level processes, includes a process workflow and modeling engine, supports policy administration, provides support for configuration items and relationships, autodiscovery, reconciliation of discovered data, data federation. Works with Peregrine and Remedy.

Focus for Tivoli Process Solutions: Release Management, Availability Management, Integration Life-Cycle Management.

Web Services in the Enterprise (Frank Kenney): Not about having services but about controlling them. Theme emerging from conference so far: important thing is to ensure that what is provisioned is supported. Show customers (partners, end users) that management layer is in place. Kenney discusses ESBs, APS and middleware, as well as vendor strategy, in considering the management of web services. (Wonder what Radovan Janecek at Systinet would say about the ESB point.)

I’m going to diverge from Frank’s talk for a second and bring it back into an IT Services Management framework. ITIL would say that there are several processes that connect to a hypothetical web service: service level management, configuration management, and availability management are key. Unfortunately a lot of ITIL implementations begin with a focus on incident/inquiry management and (if you’re lucky) problem and change management. This is good, but it’s still a reactive situation. If you’re managing proactively, you’re monitoring your services so that you can actively gauge when you’re meeting your service levels, not reacting when someone tells you you’re out of compliance, at which point it’s too late.

The issue is that there are tradeoffs in how you monitor the services. Frank covers that, but also has some interesting insights about the market as a whole: considering 12 major vendors in the market, there’s less than $50 million in 2004 revenue across all of them and fewer than 100 production customers. Also consider that many of the firms are on their second or third rounds of funding, and consider their exit strategy — likely acquisitions — before you buy.

Implementing ITIL (Shafqat Azim): suggestions include defining service catalog up front, defining dependencies (messaging systems, reporting systems); manage communications about benefit of process up to management and out to users; have a clear taxonomy and way of describing the scope of your initiative; have a clear vision of where you’re going; look at a reference model with enough depth to know the challenges and dependencies that you will be facing. Consider the level of maturity of processes on which you are dependent. Focus your effort on a handful of processes to refine, but consider how to mitigate the weaknesses of the other processes.

Validate process through use cases of particular issues—implementing a server, responding to change, etc.

Once you have the organizational requirements and use cases, think about tools. The process comes first; tools come second. (Is this ever not true?) Use use cases to develop matrix of functionality for automation, and have a bake-off.

This is all fine, but: I wonder where the trade-off is between process paralysis and avoiding useless tool expenditures.

The opening Gartner keynote is a tad condescending in the opening (who told Gartner’s CEO to cite “portal software” as an example of complex new IT challenges?), but quickly gets more interesting and starts delivering some insights, including: a quote attributed to Ezra Pound (“Man is an overcomplicated organism. If he is doomed to extinction it will come from a want of simplicity”—source?) and a citation of the Law of Requisite Variety. Complexity is a bell curve; claims there is an inflection point beyond
which if you make a system more complex value diminishes rather than increasing. They
suggest a consideration for review and acceptance of technology: “positive return on complexity.”

They make a very strong case that one way to mediate complexity is through process. Sounds good to me—that’s what ITIL is all about. Also useful: consider where to place complexity: away from the users. Don’t make IT’s life easier at the expense of the end user experience.

There’s a tradeoff between business needs and managing complexity. Also deep relationship between complexity and change management. Framework for understanding n-order change (this is when people start leaving): understand interaction between cultural systems (org structure, people) and technology systems (technology and tasks). First order change: tasks affected. Second order change: tasks and people. Third order change: affects every single variable, e.g. ERP. Fourth order: affects partners, customers, and other external connections.

Here comes the sale: there is a Gartner decision framework that helps you think across the strategic issues in managing complex new projects.

(Aside: wonder if there is a point to be made that blogging got adopted and is a profoundly transformative technology precisely because it’s less complex than other knowledge management tools?)

Managing complexity checklist:

1. Standardization: can reduce complexity or increase capacity to manage more complexity. One consideration: number of vendors and products, but be careful of lock-in.
2. Automation: from the traditional (adding additional tools to replace human labor) to augmentation (e.g. expert systems). Can hide complexity, but frequently not from IT; also raises the bar for IT staffing and pay.
3. Best practices:
   1. Don’t do everything at once.
   2. Buy what you need, not what you might need.

Remember process! This is the connection between the organization and technical complexity.

I don’t know how much blogging I’ll be doing at the Gartner conference, but apparently the conference organizers have already beaten me to it: check out the official conference blog. And they are offering to point to other blogging coverage from attendees. Cool. Next thing you know they’ll be rockin’ it unconference style. Or not. All I know is, if there isn’t a backchannel for this conference I may have to start one.