Planning for IT
By Charles Betz
hy is managing IT so hard? people, stock of goods, or information. for IT is inevitable and necessary for such
Consider this old chestnut: A Vendors such as Oracle, PeopleSoft, and emerging areas as business activity mon-
scientist gave a lecture on SAP build sophisticated, process-centric itoring (BAM), business process model-
basic cosmology at a local library. solutions on complex information struc- ing (BPM), IT service management,
Afterward, an elderly woman came up tures implemented in relational databas- increased outsourcing effectiveness, and
and asserted, “You know, the world is es for the business organizations that other goals. Figure 1 depicts one represen-
really just sitting on the back of a gigan- manage the enterprise resource. tation of major process and data areas con-
tic turtle.” Of the major resource areas, only verging into the ERP for IT space. This
“But what is that turtle standing on?” information (i.e., IT) lacks such com- model is narrowly focused on the modern
“Another turtle.” prehensively integrated vendor solu- IT organization as it’s typically structured.
“And what is that turtle standing on?” tions. Reasons for this include: From the top of Figure 1 clockwise:
“You can’t fool me, young man; it’s Enterprise architecture includes
turtles all the way down!” • The concept of information as a high-level functional and process model-
The enterprise IT problem is a stack resource is relatively new. ERP sys- ing, software portfolio management and
of turtles. We’re seeking data about the tems in other areas are founded on program management, data management
data and process to manage the process- decades-old business processes such at the higher levels, and platform strate-
ing. This article attempts a brief as dual-entry accounting. gy (e.g., technologies, vendors, stan-
overview on these IT management prob- • Infrastructure budgets in IT emphasize dards). The IT finance capability also
lems and what’s needed to more effec- hardware and often aren’t directly tied arguably belongs here. Without a firm
tively automate them. The problem is so to high-visibility, business-sponsored footing in enterprise architecture, the IT
complex that no one vendor can cover it projects. So the potential IT ERP soft- ERP effort will prove rudderless. The
all; a common framework is required. ware market is seen as limited. executives paying for IT at the highest
• The process discipline imposed by a level think in terms of the macro-level
ERP for IT true IT ERP solution would generate functions and processes defined in the
Want to get senior IT executives’ friction in most IT shops, especially if enterprise architecture; these must be
attention? Ask them, “Where’s your it involved short-term pain for high- integrated into the IT ERP solution.
ERP solution?” visibility, business-sponsored pro- Software and systems development
Ralph Szygenda, CIO of General jects. Such projects have low toler- is what most people think of when they
Motors, and his senior staff are chal- ance for overhead imposed in the hear IT, although operations and mainte-
lenging their vendors for ERP for IT. interest of longer-term IT efficiencies. nance take most of the actual IT budget.
Now that such prominent members of • Finally, there are formidable techni- This domain includes both custom-built
the IT community have raised the call, cal challenges, such as establishing and package solutions, and as related to
it’s time to look at some of the issues workable information models for the ERP for IT would cover all the tools used
and make a few recommendations. problem domain. to deliver software, including project
ERP software comprehensively man- management packages. Without integra-
ages the needs of a major enterprise IT Problem Domain tion between the software development
resource area: money, productive capital, Nevertheless, a convergence into ERP life cycle and the IT ERP capability:
business integration journal takeaways
• Despite its success building solutions for capabilities such as finance, • IT itself is probably the most challenging business area in which to
supply chain, and human resources, IT’s own internal systems and apply information and process modelling techniques.
processes often are fragmented, inefficient, and redundant. • However, this complexity is mitigated by the fact that large-scale IT
• Desire for more effective outsourcing in particular is driving the call has similarities across all industries, and is ripe for standardization.
for “Enterprise Resource Planning for Information Technology.” • The Object Management Group should step up efforts toward com-
• However, no vendor currently offers a comprehensively integrated pleting the Software Portfolio Management Facility in particular, a
ERP suite for IT, and this provides an opening for standards-based draft specification with great relevance to the ERP for IT problem.
Business Integration Journal • November 2003 39
embodied in low-level artifacts. This is
a significant theoretical challenge and
the subject of much research.
Su Unlike the others, this isn’t a well-
p established area in and of itself; its capa-
(e. por d en
g., tin bilities may be found spread across soft-
g an m
ma asse IT p e lop
ar e ware development, element management,
na t & ro
ge c ce ftw dev operational monitoring, and configuration
me ha sse Soms management. However, it’s a useful area
nt) nge s te
ys to consider as distinct, and might emerge
s as an IT area of practice in its own right.
An ERP for IT function without an
ERP audit capability will have the credibility
of a financial ERP package not backed
rt, for IT Ele by any audit. Without actual inventory
,s up nce me of what’s in the data center and labs,
ns na n
tio ainte nal) (te t ma process exceptions won’t be identified,
Op nd m ncti ch na
nic ge unused resources will remain allocated,
a (fu al) me rogue projects will be free to continue,
n t and a true accounting of operational
costs will remain elusive.
Operations, support, and mainte-
nance are the primary “heads-down”
capabilities in the IT world itself, requir-
ing call centers, continuous staffing, and
the like. These more functionally orient-
ed capabilities are distinct from the
Figure 1—The ERP For IT Grand Convergence deep, specialized technical element
management teams that support them.
• Effective portfolio and program man- cesses or systems. For example, a change The software solutions here tend to
agement will remain elusive. ticket may tell a DBA to create a table, but be fairly mature, but silos. For example,
• Development will continue in frag- the definition of that table is too often a it isn’t generally possible to correlate
mented and non-standard ways (hinder- manual, dual-entry process, with no auto- operational exceptions back to the soft-
ing the rationalization of outsourcing). mated routing of the technical specifica- ware development process that created
• Deployment and software inventory tion (let alone execution managed by auto- the defective software. Were inspections
processes will continue to be haphazard. mated software release management). and testing fully carried out?
• Traceability between software pro- Without alignment between IT ele- For another example, there’s a gap
jects and their delivered run-time ment management and ERP for IT, these between the operations/help desk capabil-
code will remain weak, perpetuating deep, essential areas will continue with ities and enterprise architecture concepts.
poor quality software. limited visibility to senior executives. A An oft-stated vision in much recent prod-
craft mentality will persist, hindering uct literature is the goal of end-to-end
Technical element management is a improved automation. Finally, the busi- traceability, which is shown in Figure 2.
general category for all the IT infra- ness impact of critical IT incidents Some operations solution vendors are
structure areas requiring specialized (which often first manifest in these areas) starting to support high-level semantics
tooling and skills, including: will remain obscured, and business activ- to bring BAM-type capabilities to opera-
ity monitoring (BAM) of IT operations tional monitoring. However, this begs a
• Network and systems administration will remain elusive. question. How are the processes to be
• Database administration IT audit/discovery: Many times, IT described? A rich process modeling lan-
• Messaging administration systems are built or altered without prior guage is required and it’s doubtful that
• Extraction, transformation, and load- documentation. This is where scanning/ operations- and help desk-focused ven-
ing (ETL) administration. discovery/reverse engineering comes in. dors can accommodate sophisticated
This includes all the tools and techniques modern enterprise architecture software
Any one of these areas and others can by which computerized systems can be such as Popkin or Ptech.
contain a person’s lifelong career path, understood. Examples include data profil- The enterprise architects and analysts
and as capabilities, they usually have ing, application mining, program under- responsible for BPM will demand com-
strong, distinct teams—hence the differ- standing/reverse engineering, system fin- patibility with their preferred tools
entiation between element management gerprinting, automated technology rela- rather than manually re-enter their mod-
and general operations/help desk. tionship mapping, and more. els in process modeling bolt-ons to
Today, they’re often stand-alone silos The more advanced techniques and operations frameworks. Integration
with a craft mentality and insufficient tools seek to tease out the emergent based on industry standards is required.
integration with overall enterprise IT pro- architectures and design patterns Without a direct link to operations or
40 Business Integration Journal • November 2003
Given a business function
or process, what is its complete
manifest (footprint) of
supporting technology devices
and operational capabilities?
Given a specific element
of technology, what business
processes or functions does
it enable and/or impact?
Figure 2—End-to-End Traceability
help desks, an ERP for IT package will is a matrix demonstrating the possible this, including various efforts to standard-
be unable to correlate key cost informa- relationship between the OMG standards ize necessary semantics. These efforts
tion on operational activities back to the and well-known IT process models. A converged in the work of the OMG, with
business processes they support, and the similar analysis could be done for lower- its layered modeling paradigm.
upstream design/build activities that ini- level standard models developed by the There’s no meaningful competition to
tiated them. Such traceability is essential Distributed Management Task Force. The the OMG’s work, which can absorb and
to managing IT costs rationally, prioritiz- point is that IT has rich, robust standards represent virtually any modeling language
ing support and maintenance activities, for both process and data, yet little work imaginable, including the Common
driving software quality, and managing has been done to integrate them. Warehouse Metamodel, which supports
IT operational risk. Without the common rationalization entity/relationship modeling. The OMG
Supporting IT process includes and centralization of these processes in isn’t just about object modeling any more;
those executed by smaller IT work- an IT ERP solution, they’ll continue to they’ve defined the equivalent of TCP/IP
groups outside the data center and help suffer from inconsistent interpretation for modeling languages and metadata.
desk. These various processes help inte- and application, poor data integrity due Such standards unification will enable
grate the software development life to multiple masters and unclear mainte- creation of an ecosystem of ERP IT ven-
cycle into the enterprise (i.e., change nance protocols, uncontrolled, hairball dors specializing in various areas, assured
management), as well as providing con- interfaces, and a host of other common of their solutions’ interoperability
figuration management, asset manage- problems. IT is its own worst cus- through protocols such as XML Metadata
ment, systems deployment, capacity tomer—a barefoot cobbler’s child. Interchange. Without such unification, IT
planning, and other services. Let’s turn to some background and ERP will repeat the mistakes of mono-
These process areas are usually under- deeper perspectives. lithic, single-vendor ERP solutions.
served in terms of IT automation; often If the “IT Doesn’t Matter” thesis of
they’re run using Excel spreadsheets or CASE: The Previous Generation Nicholas Carr is even partially correct, it
Access databases. The complexity of There’s nothing new under the sun. supports the position that both vendors
Global 2000 IT environments and the The history of computer-assisted soft- and consumers of IT should increase
desire for their greater efficiency is forc- ware engineering (CASE) stands out as their support of standards bodies, so
ing a painful rationalization of such prac- a stark lesson for the IT ERP project. fewer resources are spent re-inventing
tices. One might argue this major area is We all know CASE failed. Or did it? commodities.
the primary driver for ERP for IT. Many strategic, mainframe-based sys-
The industry is moving toward a con- tems were built and are maintained on Metadata
sensus that this general area should be first-generation CASE tools to this day. The ERP for IT project will live and
called IT service management, and the Failure? Let’s say rather that: die by the quality of its normalized data
pre-eminent standard in this area is the structures, a situation also encountered by
U.K.’s Information Technology Infra- • CASE was oversold. first-generation CASE. Understanding
structure Library (ITIL). The major • It didn’t scale down or out well to small- the information model was the most chal-
trade association is the IT Service Man- er, more heterogeneous distributed lenging aspect of supporting first-genera-
agement Forum. architectures. tion, repository-based CASE tools.
The ITIL material focuses on “what,” • Its tooling suffered from monolithic If framed as a class or entity/relation-
not “how,” and tends to simply call for proprietary architectures. ship model (a metamodel), the major IT
the existence of a best practice. ITIL • Ultimately, it was consolidated and entities might be:
badly needs reference information and milked for licensing revenue; invest-
process models; earlier incarnations of ment stagnated. • System
ITIL had more of this sort of analysis • Component
than the current iteration. This isn’t nec- But much of the IT ERP effort will • Feed (or flow)
essarily bad, as other organizations and reflect the problems of first-generation • Process
consortia—such as the Object Man- CASE; the leaders of the IT ERP project • Event
agement Group (OMG) and the Dis- should review this history. Some of the • Interface
tributed Management Task Force— industry’s brightest minds put much high- • Datastore
engage in complementary work. Figure 3 quality (and still relevant) thought into • Data element
Business Integration Journal • November 2003 41
• Project valid relationships between CIs. Gartner The Abstraction Problem
• Document has also identified a new industry sector The issue of metadata leads to the log-
• Artifact/deliverable called technology relationship mapping ical/physical (or “what vs. how”) distinc-
• Party (individual or team) represented by vendors such as Troux. tion, identified years ago. This isn’t a dis-
• Device The emphasis again is primarily on the cussion of data modeling, although data
• Incident. graph and much less on the valid seman- is a good place to start in understanding
tics of the various node connections. the issues of abstraction. EAI and busi-
It’s a tough problem area to model. Less radically, the OMG’s family of ness processes also require logical/physi-
The subtyping hierarchies are deep, modeling languages, descended from cal mapping. For example, a high-level
recursion is rampant, and many-many classic entity-relationship modeling, is integration diagram might show systems
relationships are numerous. The need to the leading candidate for industry stan- as key abstractions with the interfaces
support abstractions (e.g., logical/physi- dards. Most of the core IT concepts listed between them as simple lines. A physical
cal) compounds the problem. above can be found in current, approved decomposition of this would show the
None of these requirements are well- or pending OMG standards. However, the actual components, servers, and queues
supported by mainstream relational OMG’s work has some key gaps for an IT implementing the source and target sys-
database technology. Leading metadata ERP solution. Modeling IT’s financials in tems and the data flow in between.
platforms are therefore based on an particular appears to be poorly addressed. Tracing from the abstraction of what a
object-oriented (OO) layer that supports The standard of greatest relevance to complex system does to the reality of
robust inheritance, OO associations, and enterprise IT—the Software Portfolio how it’s physically built is a problem no
graph queries. Management Facility—has languished in other ERP domain faces in quite the
In fact, a new trend in metadata is the the OMG’s approval process, overshad- same way. Both physical and logical
highly graph-centric approach, emerging owed by the current Unified Modeling metadata suffer from distinct challenges
as perhaps an overly extreme response to Language (UML) revisions. Moreover, in and of themselves. The additional,
the difficulties of metamodeling the IT there are competing efforts (e.g., the critical task of mapping between them is
problem domain. For example, the ITIL Distributed Management Task Force, the expensive and difficult. The OMG’s
concept of a “configuration management Business Process Modeling Language Model-Driven Architecture attempts to
database” uses configuration item (CI) as [BPML] effort, and more academic work address precisely this challenge.
a catchall general type for any item of around ontologies and the wemantic Conceptually, physical metadata is rel-
interest to IT’s internal processes. How- Web). The IT ERP project needs to iden- atively straightforward to understand.
ever, ITIL doesn’t seem to call for a tify and back the standards players with There’s little dispute about what things
robust relationship model (e.g., subtyp- the greatest commitment to interoperabil- are. It also is amenable to automated dis-
ing, cardinality, and other constraints) ity, a commitment noticeably lacking in covery and correlation processes, and the
with which to describe and enforce the the BPML leadership, for example. tooling in this area becomes more
Object Management Group Standards
Software Process Engineering Metamodel x x x x x
Unified Modeling Language x
Component view x x x x
Deployment view x x x x x x
UML Profile for Enterprise Application Integration x
Enterprise Distributed Object Computing x
Organization Structure Facility x x x x
Common Warehouse Metamodel x x
Entity/relationship x x
Relational x x
Software deployment x x x x x x
Warehouse operations x x x
Figure 3—Process-Centric vs. Informatioin-Centric Standards
42 Business Integration Journal • November 2003
sophisticated every year. System B, data moves between them pass its potential, it must start by building
Logical representation, on the other and business processes are supported. on the ongoing attempts to standardize
hand, requires: This is much harder than the data ques- CASE. In fact, CASE might be redefined
tions above. In the data world, we know as Computer-Assisted Systems Engineer-
• The creation of sophisticated consen- that schemas contain tables that contain ing to better reflect the configuration man-
sus among a community of users columns. With integration flows, we have agement and operations components. The
about what the key abstractions mean no such certainty. Generally, we can know OMG standards clearly represent the cul-
• The use of those structures in expen- neither the number of “hops” nor their mination of attempts to standardize CASE
sive collaborative analysis to actually type, between two endpoints before query and are the leading option for a foundation
build out a logical conception of the execution. We also may want to artificial- that could bring everything together.
enterprise systems. ly limit the scope of the hairball pulled The alternatives aren’t satisfying. A
back into the report because everything major IT vendor might declare the first
The first consensus has proved elu- may be connected. IT ERP solution, attempting to become
sive unless the logical metamodel (the Logical/physical: The logical/physi- the PeopleSoft or SAP of IT. There are
concepts or language used to describe cal problem is especially acute with smaller vendors already claiming this,
the logical system) is carefully crafted. If integration because both the logical and but they don’t begin to approach the
too complex, people become bewildered physical integration worlds require scope outlined here. Complete coverage
and tune out. If too simple, people have graph structures to manage their data would be a formidable challenge for a
to interpret the concepts and misalign- (they’re both hairballs) and tracing single vendor if that vendor sought to
ment easily emerges. high-level information flows to their avoid any use of industry standards and,
Even when the logical metamodel is physical implementations is a signifi- instead, imposed a proprietary approach.
well-established, maintaining the metadata cant challenge. The problem isn’t just However, it’s clear that the big players are
in it (and keeping it traced to lower and one hairball, but at least two, and each starting to think about their strategies in
higher levels) has historically proven cost- and every strand of hair in one ball must this area. For example, HP has extended
ly and challenging, resulting in an unfortu- be tied to its counterpart(s) in another. its OpenView suite; IBM has offered its
nate yo-yo commitment to disciplines such Presentation problems: IT depart- OMG-based eMOF foundation.
as enterprise architecture. Logical/physical ments traditionally create large diagrams Another scenario might be that GM
is important because, in decision support documenting systems architectures. As starts to drive the whole project, much as
sense, the physical rolls up into the logical. the late Dr. Bernard Boar lamented, such Wal-Mart has started to impose its sup-
Executives rely on rollups as abstractions. diagrams usually follow no blueprinting ply chain protocols on an entire industry.
In the IT problem domain, the dimensions standard, but do embed common under- Clearly, a standards-based ecosystem
are many and nowhere near as well-estab- standings and serve as important refer- allowing rich specialization and niche
lished as classical data warehousing hier- ences. These diagrams typically aren’t players all based on the common OMG
archies such as item, time, and location. stored in repositories, although that semantic bus would be ideal.
would be ideal for management and Enterprise information technology, if
Integration Metadata accessibility. Ideally, such diagrams not the hand that steers the rudder, is at
One area not well-addressed by any should be simply specialized views of least the hinge upon which the rudder
standards or notations is precisely docu- one integrated model. pivots. It’s highly leveraged and any
menting integration among large, het- Repository-based data modeling improvement in its management should
erogeneous, distributed systems. This is tools have such capabilities. However, a have a multiplier effect on the enterprise’s
a requirement for any solution purport- key enabler for data-centric CASE tool- effectiveness. An industrywide improve-
ing to provide an ERP for IT capability. ing was the emergence of entity/rela- ment could have a similar, positive effect.
Challenges include: tionship diagramming as a consensus Onward to IT ERP!
The heterogeneity of the EAI language for describing data. A similar The author acknowledges John Schmidt,
world: The integration problem encom- common language is required for inte- Pete Rivett, Sean Goggins, and Peggy Dora
passes a bewildering variety of tech- gration and systems engineering. for their feedback on this article.
nologies: messaging, FTP, database Possible solutions: Architecture
middleware, application servers, mes- Description Languages (ADLs) have About the Author
sage brokers, and more. been a popular avenue of investigation.
The “hairball” nature of metadata: The OMG has also made several attempts Charles Betz
A data dictionary is amenable to stan- to support this area, but the ADL com- heads the Metadata
dard reporting techniques, to answer munity has been skeptical of UML for Management Office
for electronics retail-
well-defined questions such as: architecture description. The forthcoming
er Best Buy. He previ-
UML 2 standard reflects some of these
ously worked for
• What columns are on this table? critiques and there’s been other relevant
Target Corp. (where
• What tables are in this schema? OMG work. Some of these standards, he built that com-
• What schemas are in this database? however, are highly complex, and there pany’s metadata repository), and also for
are usability questions. Andersen Consulting as technical architect for
Integration metadata, by contrast, is ERP solutions. Voice: 612-251-9888; e-Mail:
concerned with end-to-end semantics. It Future Directions firstname.lastname@example.org; Website: www.erp4it.com.
explores how, given System A and If the IT ERP project is to truly encom-
Business Integration Journal • November 2003 43