Enterprise Resource Planning for IT


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Enterprise Resource Planning for IT

  1. 1. Enterprise Resource Planning for IT By Charles Betz W 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 BUSINESS TECHNOLOGY • 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. approaches. Business Integration Journal • November 2003 39
  2. 2. embodied in low-level artifacts. This is a significant theoretical challenge and architecture the subject of much research. Enterprise Su Unlike the others, this isn’t a well- p established area in and of itself; its capa- (e. por d en t 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 po 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, era o Op nd m ncti ch na nic ge unused resources will remain allocated, reverse engineering a (fu al) me rogue projects will be free to continue, Discovery, audit, 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
  3. 3. Given a business function Technology View or process, what is its complete Business View 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
  4. 4. • 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 CMM ITIL Configuration Management Object Management Group Standards Problem Management Release Management Process Management Change Management Incident Management Project Management Data Management Engineering Support 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
  5. 5. 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 charb@visi.com; 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