Why Is EA So Important? Jeff Tash, ITscout Flashmap Systems, Inc. ([email protected]) (www.FlashmapSystems.com) Abstract Discover how and why companies ought to transform themselves from IT cultures driven by cost and quality control to enterprises that can profit from creative IT thinking. Designing innovative IT architecture requires visionary talent. Success depends on turning enterprise architecture into a core methodology of innovation. This requires learning how to communicate complexity by simplifying and synthesizing. Introduction EA is a two-letter acronym that stands for “Enterprise Architecture.” Unfortunately, if one were to ask people who work at most enterprises to define EA, the majority would likely frame their definition in terms of a completely different two-letter acronym -- BS! It’s not that they’d necessarily be lying to you. Indeed, they’d probably honestly believe what they were telling you. Rather, the problem is that most wouldn’t have a clue what they’re really talking about. The difficulty in trying to define EA begins with the term “architecture.” If you were to look at the construction industry, you’d find very little confusion about what an architect does. One can hardly imagine trying to build an office building, a new residential house, or even adding a room onto an existing home, without first procuring the services of a professional architect. It’s pretty clear to everyone involved in the construction business what an architect does and why builders need one. Similarly, I seriously doubt there’s much controversy, if any, regarding what kind of work is performed by a landscape architect. If, on the other hand, one were to ask a dozen different IT architects to define “architecture,” they’d probably wind up with at least two dozen different definitions. Much of this confusion stems from the fact that so many different job titles include the term “architect.” Besides enterprise architecture, there’s software architecture, network architecture, security architecture, data architecture, information architecture, systems architecture, storage architecture, hardware architecture, computer architecture, application architecture, technical architecture, service-oriented architecture, plus who knows how many more! Copyright © 2007 Flashmap Systems, Inc. 1 What is EA? At its core EA is the bridge between business and technology. It’s EA’s job to translate internal and external technology forces so that business managers can anticipate and prepare for future changes that might affect business processes. In other words, EA helps place IT squarely where it belongs: in the hands of business executives under whose direction it can create the most value, thereby helping to ensure alignment of IT capabilities with the needs of the enterprise. Harnessing EA can produce massive business benefits -- not the least of which involves innovation -- by guiding the integration, design, construction, deployment, and management of IT solutions through principles, policies, standards, and models that reflect business strategies, requirements, and constraints. Disruptive Innovations IT investments can help businesses achieve competitive advantage, especially at companies where IT is recognized as a major part of a firm’s product or brand, or where information technology is used to create the kind of disruptive innovation that results in massive industry change. For example, look at Wal-Mart’s phenomenal success. They are the world’s largest retailer today largely because of how they have effectively deployed IT in a manner that has redefined the industry’s whole concept of supply-chain management. Similarly, consider manufacturing firms. Can you imagine any company larger than a Mom & Pop operation trying to run a modern-day factory without IT-enabled ERP? How about sales and service? What kind of business nowadays isn’t heavily dependent on IT-enabled CRM? Then there are whole new IT-enabled markets. Companies such as Amazon and eBay have totally revolutionized consumer buying patterns. Google has almost single-handedly transformed the entire advertising industry. The bottom line is that IT and innovation go together like bread and butter. Moving forward, there will be ever greater expectations for business and IT to work more closely together to conceive, assemble, deploy, operate, and enhance systems that are far better at engaging customers and delivering improved results. Rethinking IT Strategy Most enterprises manage IT in just one way. In short, they primarily want to lower IT costs while simultaneously increasing support for business growth. The most common, Copyright © 2007 Flashmap Systems, Inc. 2 time-tested modus operandi for managing IT has been to cut costs during rough times and fund projects when business is good. Unfortunately, many IT organizations are in a deep malaise. They’ve been focused since the beginning of the millennium almost exclusively on cost control. For far too long, they’ve been conditioned to expect their performance targets to be continuously raised and their overall budgets and headcounts to be cut. As their organizations have downsized, rationalized, outsourced, and offshored -- all in a never-ending quest for savings -- their IT management teams have become increasingly thin and homogeneous. Worst of all, most remaining managers are expert at executing the last generation of IT activity. The bulk of their time, work, attention, and funding has gone to “problems” rather than to “opportunities.” The hallmark of IT used to be that of an innovation enabler. But, today, IT is more often than not seen as a barrier, slowing the pace of innovation. On the other hand, because the IT industry is currently facing major discontinuities, now may be the perfect time for businesses to once again consider using information technology to innovate. Today more transistors are being produced annually than grains of rice -- and at a lower cost. There already exists in the world over 2 billion mobile phones and almost 1 billion PCs. Business executives would like their enterprise IT systems to be no less user-friendly than iPods or digital cameras. Yet, most business managers feel the technology they have at home is far better, faster, and cheaper than what they experience in the office. Innovation was once the cornerstone underlying information technology. But ever since Y2K, and then the dot com bomb, enterprise IT innovation has pretty much stagnated. Nevertheless, technology has continued its inexorable march forward with ever more transistors on a single chip -- now delivering multi-core microprocessors that combine two or more independent processors onto a single integrated circuit (IC); ever more bandwidth -- both wired and wireless -- at pennies per gigabit per second; and ever more storage at costs that approach a billionth of a cent per byte. As George Gilder pointed out in his October 2006 Wired Magazine article entitled The Information Factories: “The recent explosion of hard disk storage capacity makes Moore's law look like a cockroach race. In 1991, a 100-megabyte drive cost $500, and a 50-megahertz Intel 486 processor cost about the same. In 2006, $500 buys a 750-gigabyte drive or a 3-gigahertz processor. Over 15 years, that's an advance of 7,500 times for the hard drive and 60 times for the processor. By this crude metric, the costeffectiveness of hard drives grew 125 times faster than that of processors.” Looking ahead, at the present time, at least three major technological trends are combining together to create the new next-generation IT platform. The goal of these three technologies is to deploy and better assure the interoperable performance of technologies, systems, information, people, and processes. Copyright © 2007 Flashmap Systems, Inc. 3 #1: AJAX AJAX is that part of Web 2.0 that will absolutely, positively have a significant impact on IT. Microsoft has enthusiastically jumped onto the AJAX bandwagon. For instance, check out how they have drastically redesigned their company's home page www.microsoft.com by using AJAX to dynamically load content when the user clicks on items in the floating menu to the right of the page. Dynamically loaded content gets displayed in a floating panel that appears over the top of the rest of the page, which gets dimmed and cannot be clicked while the panel is visible. To the user the interface is the system!!! AJAX provides the rich client behavior that was so predominant before Web browsers became popular. With AJAX, gone is the notion of constantly having to refresh an entire web page for each transaction. With dynamic reloading of portions of web pages, transmitting only a small amount of data to the client, the resulting user experience is faster, richer, and arguably better in terms of functionality. Google has long been an ardent AJAX supporter. For example, see Google Maps (maps.google.com) which enables users to drag a map to move it in various directions, or Google Suggest (www.google.com/webhp?complete=1) which provides suggestions from the server as users type, showing in a drop-down box a list of search terms that may be of interest. Invest in AJAX. Rich clients are worth it. Historically, display terminals like IBM 3270s displaced keypunch machines. Character-based terminals like DEC VT100s displaced 3270s. Character-based PCs with memory-mapped I/O like MS-DOS displaced VT100s. Graphical user interfaces (GUIs) like Windows displaced MS-DOS. GUI browsers like IE (or Firefox) displaced PC-based GUI apps. AJAX is the next major user interface revolution and it’s happening now! # 2: Service-Oriented Architecture Microsoft, IBM, HP, Oracle, SAP, BEA, and just about every other software vendor are all now singing the same exact tune -- that SOA represents their next-generation IT development and deployment strategy. Of course, the $64,000 question still remains “What's a service?” An effective, functioning service-oriented architecture requires the ability to share services across multiple business units and enterprises. This demands orchestration between services as well as governance. Otherwise, you end up with just a bunch of services and a spaghetti-oriented architecture. Copyright © 2007 Flashmap Systems, Inc. 4 The software industry has been promising reusable components ever since the invention of subroutines. The problem invariably boils down to the age old dilemma of how does a developer “find” a software module to be reused. If the process of discovery takes as long as creating entirely new software, the developer always opts for the latter, especially if the reusable software is perceived as being unlikely to handle 100% of the requirements for the new task at hand. Software reuse -- whether we're talking a service, a component, an object, a module, a subroutine, a macro, or whatever -- is always, in fact, a two-part issue: 1) finding the software to be reused; and 2) being able to modify the software to handle non-generic special cases. The first challenge is one of figuring out how to organize, classify, and categorize the software to be reused so that it can be readily found. The second question involves supporting techniques for either adding new functionality to software to be reused, or overriding existing functionality. Fundamentally, SOA's success will largely depend on evolutionary advancements that can extend software components beyond SOA's predecessor technology, object-oriented programming. The big breakthrough that SOA delivers is in the way that it uses the Internet's underlying Web infrastructure in place of OO's CORBA and DCOM object request brokers. XML is the key enabling technology that makes all this possible. One of the keys to building successful SOA-based systems is to exploit the abstract semantic relationship that reflects the continuum between generic and specific. In other words, SOA needs to allow developers to create generalpurpose building blocks that can easily be extended to handle special cases. This is accomplished by supporting mechanisms for developers to add new functionality or override existing functionality. Another critical aspect of SOA pertains to business process modeling. Whereas services represent the core components of SOA, developers still need to be able to find those services in order to reuse them. It just so happens that the most reusable facets of any information system are its business events. A specific business event triggers a business process which itself is a set of distinct steps, some of which must be performed in sequence, others of which may be able to be performed in parallel. Furthermore, some process steps are conditionally performed based on the results of prior activities. One key to SOA's success depends on its ability to organize, classify, and categorize services based around business events (so that those services can be easily discovered). #3: Cloud Computing Servers reside in an Internet cloud somewhere and it doesn't matter when you access the cloud whether you have a PC or a Mac or a Blackberry or a cell Copyright © 2007 Flashmap Systems, Inc. 5 telephone or whatever. Nowadays this notion of cloud computing is often being referred to as SaaS which stands for Software as a Service. The pendulum in computing relentlessly swings back and forth between personal and shared machines. The very first computers, such as ENIAC, were single user systems. Those computation workhorses were soon followed by sharable mainframe computers like IBM's System/360. Next came minicomputers from companies like DEC which were, once again, primarily single-user systems. Soon, however, minicomputers became much more powerful enabling them to be shared by multiple different users simultaneously, where each user had his or her own virtual machine, and the shared resources were controlled by a sophisticated operating system such as UNIX or VAX/VMS (or various other derivatives of MIT's Project Multics). Minicomputers, though, soon were made obsolete by personal computers which gave each virtual machine user their own physical machine to control. But, PC users still wanted to share data and resources just as they had previously been able to do on their shared systems. That demand led to the advent of client/server computing. The ultimate winner in the client/server war was the World Wide Web which itself is evolving into cloud computing especially as behemoths such as Google and Microsoft build massive data centers with massively parallel processing capabilities constrained only by their ability to find enough electricity to power their truly amazing infrastructures. Architect Now Companies ought to transform themselves from IT cultures driven by cost and quality control to enterprises that can profit from creative IT thinking. Designing innovative IT architecture requires visionary talent. Success depends on turning architecture into a core methodology of innovation. This requires learning how to communicate complexity by simplifying and synthesizing. In most enterprises it’s the architects who will be the people responsible for bridging the chasm between the cultures of business and technology. It will be their job to educate, inspire, cajole, hire, bribe, punish, build -- all to transform their companies' cultures. To succeed they’ll need to tear down silos, mix people up, bring in outside change agents, stimulate people's minds, and generate a diversified portfolio of promising ideas. Their mission will be to redefine the whole meaning of the term “application” to where businesses depend on services that are combined, mixed, matched, mashed and reused as needed. Innovation means implementing new ideas that create value. The innovation process must start with business executives who can clearly understand, and then articulate, the directions where they want their organizations to go. Additionally, these business leaders need to be able to communicate goals to their IT management teams. Further, both the executive and IT management teams need to know how to apply their enterprise's vision to the specific plans, programs, people choices, projects, responsibilities, and accountabilities that will enable the growth that they seek. Finally, both sets of leaders Copyright © 2007 Flashmap Systems, Inc. 6 have to possess the execution focus and discipline that’s needed to turn their plans into reality. Delivering long-term success depends on both these two groups -- business and IT management teams alike -- being able to develop relationships based upon credibility, understanding, and trust. The overriding goal of enterprise architecture is to allow an organization to think about and manage technology in precisely the same way that it currently knows how to think about and manage money, people, and property. EA’s role in bridging the gap between business people and technology people is to enable these widely divergent audiences to all share a common vision and a common vocabulary. EA tackles the challenge of establishing a common set of expectations by addressing four separate architectural components: 1. 2. 3. 4. Business Architecture Data Architecture Application Architecture Technology Architecture Business Architecture Business architecture is based on the logic of rational organization and production. Rationalization works by applying scientific management to the creation of defined, quantifiable, repeatable production and organizational processes. Almost every facet of modern industry takes some quantifiable process, maximizes it for efficiency based on a distinct division of labor, with defined inputs and outputs, and then manages it based on a rules-bound bureaucratic structure. There are two key challenges facing the enterprise architect who tries to define the processes and workflows that constitute an organization’s business architecture. The first involves avoiding the quagmire of quicksand which can result from diving too deeply down into process details. Business process modeling tools -- often based on graphical UML (Universal Modeling Language) diagrams -- make it far too easy for architects to create massive, intricate models that can often obscure effective communication with non-technical business audiences. While it’s true that comprehensive, complex models do indeed capture the richness of a business reality, and do provide a great learning environment for an architect, it’s unreasonable to expect a busy manager to pore over a convolution of graphical information in order to understand what’s actually happening within their enterprise. Instead, what’s required is a high-level overview diagram that serves the same purpose as an executive summary which summarizes all the other sections of a long, complicated report. An interested manager can always drill-down to see more detailed views. The second obstacle one wants to avoid when trying to define business architecture is overemphasizing the importance of efforts such as ITIL (IT Infrastructure Library). The problem here is that ITIL does not, by itself, describe EA. Rather, it deals with only a small portion of an enterprise’s overall business architecture. A typical enterprise Copyright © 2007 Flashmap Systems, Inc. 7 generally can be described using a high-level functional decomposition which breaks down an organization into a business process view that can be represented as primary layers. Generally, there are somewhere between five and ten different primary business process layers. Each of these will themselves include multiple sub-processes, and each sub-process may have as many layers as necessary to define the organization. One of the primary business process layers will indeed be Information Technology, and ITIL may well be used to model the processes surrounding IT services. For the vast majority of organizations, though, the business processes supporting Information Technology are, like other Corporate Services, less important than those that deal with Product Development, Demand Creation, Sales, Production, Logistics, or Finance. Data Architecture Data architecture is a model mapping to critical business entities as well as relationships among entities. In other words, for each real world entity, or “thing,” such as a customer, a part, a supplier, etc., there exists a one-to-one correspondence between that real world “thing” and a representation of that “thing” as it’s portrayed in the model. Each of these “things,” or entities, includes descriptions of properties and behaviors. Encapsulation hides implementation details about data, such as the distinction between fields and operations (i.e., methods). The data architecture models the relationships between instances of real-world entities. These include one-to-one, one-to-many, and many-to-many relationships. Metadata relationships, especially inheritance which distinguishes between generic cases versus special cases, also need to be described. Composition is used to describe things made up of other things. Business executives need a cognitive roadmap to help them manage technology. They need mental models which enable them to better understand and more intelligently communicate about their enterprise’s most essential business entities. Business analysts need to view information organized using multi-dimensional attributes that can be sliced & diced or rolled-up & drilled-down. These operations allow data to be analyzed and explored so that patterns and trends can be more readily identified and understood, especially through facilitation of meaningful comparisons between various sets of related data such as different business units, geographic regions, or time periods. The beauty of the data architecture is its innate stability -- especially by comparison to the business architecture which tends to be in a continual state of flux (e.g., business architecture changes every time a reorganization takes place). The data architecture models real-world things, like customers, parts, suppliers, contracts, employees, etc. These things don’t tend to change very often. Enterprises may reorganize and reengineer all they want. At the end of the day, a customer is still a customer; an employee is still an employee; a supplier is still a supplier; etc. Copyright © 2007 Flashmap Systems, Inc. 8 Application Architecture Application architecture deals with the functional requirements of a software application that delivers business value. In other words, think of it as the “what” in terms of the functionality that gets delivered by executing software, encompassing the features, feature sets, and user-centered clumps of functionality as might be expressed in a User’s Guide or marketing brochure. It’s literally the architecture underlying the automated services that support and implement functional requirements, especially the interfaces to other systems and other applications. Application architecture describes the structure of an application and how that structure implements functional requirements. Application architecture is responsible for the combining together of portions of processes with pieces of data into separate independent software. It defines the set of API’s (Application Programming Interfaces) that enable application partitioning across distributed computing platforms. It’s also responsible for the API’s that support application integration across multiple systems. There are various ways of partitioning processing that range from fat clients to thin clients depending on how much of the code runs on the front-end versus how much runs on the back-end. In between are various ways of handling interprocess communication, some based on remote procedure calls, others based on object request brokers, and still others that depend on asynchronous message transmission. Service-Oriented Architecture (SOA) represents the next generation of application architecture technology. SOA is the perfect platform for pervasive, massively distributed computing because of how its middleware handles all partitioning and integration tasks as well as provides full support for directory and security services on top of an industry standard Internet-based Web infrastructure. One of the great promises driving SOA is that application components can be loosely coupled. This refers to a technique of designing interfaces across software modules in such a way that greatly increases flexibility by reducing the risk that changes within one module can cause unanticipated changes within other modules. Of course, a far more important goal for businesses is to create loosely coupled processes that will depend on services that can be combined, mixed, matched, mashed and reused as necessary, and where each service need not be aware of others to operate successfully. Perhaps the biggest benefit of loosely coupled software is the opportunity it creates for businesses to define processes that can operate asynchronously. The reason why this is so important is because a distributed system is significantly harder to build than a monolithic one. The reality is that networks are never totally reliable, latency is never zero, and bandwidth is never infinite. Copyright © 2007 Flashmap Systems, Inc. 9 Technology Architecture Technology architecture models technology portfolios. Technology portfolios refer to past -- as well as projected future -- technology investments consisting of all the different kinds of IT products, systems, and services an enterprise owns. Beware: technology architecture is not an inventory of assets. Asset management tools are responsible for capturing, tracking, and reporting on individual assets. Asset managers not only can tell you how many of some asset exists, but also where each asset is located. Accountants need to collect this kind of information in order to handle such tasks as calculating depreciation. Technology architecture focuses on classes of products -not instances of products. That distinction is analogous to the difference between data and metadata. Presented in figure 1 is the three-layer, fourmodel ITscout Technology Architecture Framework (see http://www.ITscout.org/). The bottom layer corresponds to Figure 1: ITscout Technology Architecture Framework Infrastructure. While extremely expensive and complex, by itself, infrastructure really doesn't do too much of anything. It just sits there. Value is derived only after Applications get layered on top. Depicted as the middle layer in the graphic, applications can either be developed or purchased. Of course, regardless of whether they're built or bought, applications generate Data -- data that yearns to be analyzed and mined for its business intelligence. That's the top layer. EA Artists Enterprise architecture that's not communicated does not add value. Success, in terms of architecture, begins with communicating the right information to the right people at the right time. This requires simple and easy access to architectural information. Communicating information visually is especially important since over 70 percent of the neurons in the human brain are dedicated to visual processing. The old adage that a picture is worth a thousand words is probably a gross understatement. In the real-world of construction where architects design buildings for a living, inordinate amounts of time are devoted to communicating -- both with the consumers (i.e., customers/clients) and with the producers (i.e., developers, contractors, sub-contractors). Initially architects produce drawings, or renderings, so that their clients can visualize what they're buying, and actually see what's going to be built using their money. Then the architects produce numerous, much more detailed drawings called blueprints that are Copyright © 2007 Flashmap Systems, Inc. 10 shared with contractors and sub-contractors who will do the actual construction work. Note that the client isn't expected to extrapolate what an eventual structure will look like based just on the blueprints. Instead, they get to view sketches that are far more meaningful and understandable to a non-technical person. Enterprise architects can't just produce UML drawings, not if they want to convey important information to business people. They must concentrate their focus on communicating architecture to untrained users. Edward Tufte, an expert in the presentation of informational graphics, explains that graphical excellence is the “welldesigned presentation of interesting data that communicates complex ideas with clarity, precision and efficiency by providing the viewer the greatest number of ideas in the shortest time, with the least ink, and in the smallest space.” Presented below in figures 2 and 3 are a couple of examples of EA artistry taken from the ITscout Technology Architecture Framework. These diagrams convey descriptions of extremely complex topics, yet the presented information can be readily understood by non-technical business executives. Figure 2 presents a picture that graphically describes the Business Intelligence Roadmap (for more detail, see http://www.ITscout.org/). The top red surface of the 3-D cube represents data. It shows how data can be captured from either internal or external database sources. Once captured, the data undergoes a three-stage process called ETL which stands for Extract, Transform, and Load. After processing, BI data resides in either data warehouses or data marts. Furthermore, the data undergoes various checks to test for data quality. The two side-by-side surfaces facing front in the 3-D cube describe the various categories of products that are used for analyzing BI data. The green surface on the left side describes tools used for query & reporting, data analysis, data visualization, or data mining. The blue surface on the right side, labeled analytics, corresponds to software available as commercialoff-the-shelf (COTS) packaged solutions. Figure 2: ITscout Business Intelligence Roadmap Copyright © 2007 Flashmap Systems, Inc. The bottom portion of the diagram, depicted by the porthole-shaped yellow portals (below the 3-D cube), signifies how most business people access their BI tools and data using browser-based portal 11 products that aggregate and standardize access to systems, applications, products, and data. Figure 3 shows the visual graphic depicting the Application Development Roadmap (for more detail, see http://www.ITscout.org/). Notice how the outer enclosing yellow ring represents life cycles. Alliteratively, one first defines the requirements. Next, they design, develop, debug, and deploy the code. Lastly, they discover what they got wrong. Then they start the whole cycle all over again. This illustration helps a viewer immediately see how different categories of tools are associated with each of the various stages throughout the application development life cycle. Figure 3: ITscout Application Development Roadmap The visual illusion that the inside section of the picture tries to convey is that of a three-bladed propeller spinning clockwise in a spiraling rotation. The red blade labeled platforms refers to Java, Dot Net, and XML. The blue blade corresponds to languages such as JavaScript, Java, C#, Basic, C++, or Perl. Lastly, the green blade represents various categories of reusables relevant to the application development process such as components, metadata, or repositories. Not BS Artists Over the past few years, many IT organizations have lost significant ground. Their IT infrastructure, internal processes, architectural consistency, and applications portfolio have fallen behind. The enterprise-wide understanding of what it takes to create IT value has diminished. EA provides IT with an opportunity to regain their management’s trust by demonstrating that they understand the business and its context. To do so, enterprise architects ought to mimic their counterparts in the construction industry. Those architects create two different sets of drawings. One type includes the set of detailed blueprints that tell builders how to construct whatever structure they’re building. The other set are sketches, or drawings, which are renderings that convey to non-technical customers a conceptual description they can readily visualize and understand. Enterprise architects need to paint pictures that explain their enterprise’s business architecture which executives can quickly understand and validate. Architects must create cognitive models that map out for business people what their organization’s data Copyright © 2007 Flashmap Systems, Inc. 12 architecture looks like. Similarly, they should visually illustrate how their company’s application architecture delivers functionality that generates business value. Finally, enterprise architects must develop a technology architecture that formally charts IT assets. Managing IT functionality as a portfolio of valued assets provides the business leverage of the future. Healthy stewardship requires tracking what’s been acquired, purchased, built, licensed, or leased. It means managing life cycles from consideration to retirement. Innovative architecture does not mean instant perfection. Architecture will naturally evolve over time. What's most important, however, is understanding that people need a vision, along with a plan on how to get to that vision. Summary The question was posed, why is EA so important? The answer is that enterprise architects, properly empowered, are able to make extraordinary, high-impact contributions based on the models they construct, and subsequently communicate, to the business people and technology people within their organization. Architects are in a unique position to articulate their enterprise’s business capabilities -- the combination of processes, systems, and people -- that serve as the fundamental building blocks for achieving overall business objectives. Invariably, EA may threaten the autonomy of individual business units. The challenge is to strike the proper balance between centralized versus decentralized decision making. This requires buy-in from many different stakeholders in order to achieve optimal consistency, consolidation, and leverage across the enterprise. The goal is to persuade everyone involved to embrace the architecture that best serves the enterprise overall in implementing business strategy. EA provides the bridge that allows business strategy to drive what capabilities are built, sustained, and jettisoned at the enterprise level, versus those that are delegated to individual business units. EA supports technology standards across the enterprise. That reduces IT complexity and costs by increasing convergence, consolidating purchases, lowering training costs, and enabling better mobility of technical staffers. EA improves collaboration among different parts of the enterprise by sharing access to information across the organization, eliminating duplication of effort, and globally addressing issues related to integration, interoperability, and security. Additionally, because EA communicates and informs more effectively, it increases an enterprise’s agility by facilitating quick responses to changes in business strategy. Enterprise architects must be highly regarded by technology workers. They must be highly credible among business managers. They need to be really good at modeling, and especially good at describing the “big picture.” The goal is always to simplify and synthesize using architecture to communicate, at a high level, how the enterprise will deliver the value established in its business strategy. Copyright © 2007 Flashmap Systems, Inc. 13 Resources • • • • • • • ARR -- Architecture Resources Repository (www.ITscout.org/Architecture) ITscout (www.ITscout.org) Enterprise Architecture Executive Report, by Dana Bredemeyer and Ruth Malan, Cutter Consortium, 2004, Vol. 7, No. 8 The Empowered CIO, by Bruce Rogow, Optimize Magazine, August 2006 (http://www.optimizemag.com/article/showArticle.jhtml?articleId=191204749) The Information Factories, by George Gilder, Wired Magazine, October 2006 (http://www.wired.com/wired/archive/14.10/cloudware.html) The Work of Edward R. Tufte (www.edwardtufte.com) Tracking Core Assets, by Bruce Rogow, Optimize Magazine, April 2006 (http://www.optimizemag.com/issue/054/bm.htm) Copyright © 2007 Flashmap Systems, Inc. 14
© Copyright 2024