Inflection Point: Accelerating Transformation
In our Inflection Point posts we dig a little deeper and take a hard look at the root of an issue currently plaguing enterprise IT by breaking down the problem(s), offering remediation approaches, and highlighting points of insight we’ve seen work with clients.
Much of IT strategy revolves around aligning IT to business objectives. (Past Blog: How Well Do You Know Your Application Relationships?) Despite all the attention, little strategic thought is expended in how to best enable rapid change. The traditional method is to first discover the current state, then develop a future state, and finally create the transformation program needed to realize the bright new future. Let’s expand on the first step “Discover the Current State”.
Consider this: Think about the path you’d take to get home from your current location. No matter where you are, it’s generally easy to imagine a path home, because we have some context on where we are physically located. Now imagine walking with amnesia in the middle of a city. We recognize some basics… appears to be a big city, but which city? What street? We lack a frame of reference… even if we have our home street address sewn into our jacket, we’d have to deduce our current location to begin taking that purposeful first step home.
IT organizations suffer continual amnesia about their IT infrastructure. Almost every change begins with expending much energy and effort to rediscover the lost current state architecture. To reduce our time to improvement, IT needs a living view of current state that’s always ready to roll to step 2.
Problem: Out-of-Date Architecture Documents
The core issue is that most system changes are statically documented. So, although large system deployments are initially well documented, the quality of that documentation decays. This is usually driven by incremental change (sometimes to the application itself; other times by changes to its deployment environment). After a number of these changes, the application deployment is significantly altered from its original configuration, and stranger still, these changes may be invisible to the application owner. Essentially this leads to documentation half-life (the time required for the document’s value to decrease by half) that is measured in weeks! Not only is the architectural view constantly degrading, the reasoning behind many decisions (if ever documented) is often lost due to turnover or the fuzz of past recollections. The more change taking place; the shorter the documentation’s half-life.
Application Discovery and Dependency Mapping (ADDM) tools can be of some assistance but don’t easily account for the human imparted attributes that convert raw resources and their interdependencies into applications. These discovery views are generally limited to the privileged few who have access to the ADDM system. ADDM tools really aren’t geared toward creating mass-consumable documentation; rather, their sweet spot has been to update CMDB information, which itself is fantastic at generating long tabular lists! Not very appetizing….
Furthermore, an application’s deployment goes beyond interconnected resources. For example, an application’s resource boundary cannot be discovered via inspection; it must be defined. This is a very time consuming task in most discovery tools and worse, it can’t be easily combined with external data (e.g. CMDB info), which may include information such as who owns or supports the application, or better yet, user demographics. Nor do such discovery tools facilitate capturing any insights into application workload characteristics.
As a result, IT leadership is stuck reacting to areas of the IT environment that are obviously broken. They only recognize the need because sharp things keep poking at them. This business-as-usual approach just doesn’t cut it anymore. Business is demanding more from the IT organization. The new expectation is that IT has the infrastructure ready to respond to the next opportunity, so the organization maintains, or event expands, its competitive advantage.
In order to solve this problem the IT needs a constantly up-to-date view of the current state infrastructure!
Solution: Living Blueprints!
Imagine having system diagrams that magically update, much like the footprints on Harry Potter’s map (can you say Mischief Managed?). No more slaving over Visio! Need to move Application A to the new data center? No problem, here’s the documentation and don’t worry about having to update it after it’s moved… that’s already done for you. Nice fantasy, or is it?
The first thing needed to make this a reality is a common information store that contains the needed relationships we want to represent. Sounds a lot like a CMDB, but most organizations can’t claim their CMDB is accurate, if it’s in place at all. OK, there’s some useful info, but it needs to be culled or at a minimum validated. Well then, what about the ADDM tools? Definitely helpful—a snapshot contains actual resources witnessed, but as noted earlier, it doesn’t contain the human insight necessary.
Combining these data sources, along with the needed human augmentation, presents its own set of challenges as there’s various degrees of trust that needs to be attended to and conflicts to resolve. Now, even if one were able to create this datamart of information, periodically refresh the data within it, and supply administrative tools to organize it, we’d still have the dynamic image rendering issues to vex us.
For over a decade now, we’ve been able to create dynamic documents via HTML and server-side scripting languages, but not so much for images. “What about Adobe FlashTM?”, you might ask. Unfortunately, Flash is great for creating UI widgets, but doesn’t really take to the printed medium very well. (There are other technical integration challenges, but they’re boring to discuss.) What’s needed is a standards-based solution similar to what has been accomplished to extend HTML via server-side scripting.
Interestingly, way back in 1999 an initiative to make Scalar Vector Graphics (SVG) was created to be for images what HTML is for documents, but it never developed a server-side scripting language. With such a language it would be possible to dynamically render SVG images as easily as it to render HTML pages.
Such a technology, bundled with the pre-mentioned datamart would complete all the elements needed to create the Living Blueprints. Innovation! (This is the Eureka moment, in case you missed it.) A cure for IT amnesia!!
Adaptivity, with its BluePrint4IT platform, has developed these two missing elements of technology and is able to enable Living Blueprints, today. Stop toiling with manual drawing tools in a futile effort to avoid IT amnesia and give us a call.
Category: Datacenter Transformation, IT Management
About the Author
Alex is Executive Vice President of Product Management at Adaptivity, and leads a critical team whose role is to institutionalize our intellectual capital as productized services, knowledge platforms and SaaS offerings. He collaborates with the CIO, CTO and CEO to ensure that we exceed client expectations with our offerings, services and products. Most recently, as Vice President and Program Manager of Architecture and Innovation at Wachovia's Corporate Investment Bank, he led a program to modernize the DMZ networking and security infrastructure through which Internet applications are hosted. This leveraged a compilation of virtualization technologies, security standards, and policy enhancements to reduce time to market and fault domains while improving protection, performance and uptime. Alex holds BSEE, MSEE, and MBA degrees from Northeastern University, Purdue University, and Duke University respectively.View Author Profile
Alex, you raise excellent points.
Most communities demand that before improvements can be made on a dwelling the plan, must be validated and most importantly, registered, then inspected. Why, well there is the noisy control freak neighbor aspect, but more importantly is the concern that changes are placed in a Known reliable and timely repository so that as time marches on, there is a record of the current state. This is critical for a community to know in case of disasters, emergencies, or continuity as the property changes hands.
As we have seen in IT, time frames are severely compressed and the resources and discipline to keep documentation relevant is not valued in its current form.