Your SlideShare is downloading. ×



Published on

Published in: Technology, Business
  • 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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. MEGA & the Zachman Framework Positioning MEGA Suite™ against the very famous Zachman Framework
  • 2. MEGA & the Zachman Framework MEGA & the Zachman Framework 1 Positioning MEGA Suite™ against the very famous Zachman Framework 1 Introduction 2 What is the Zachman Framework? 3 What does the Zachman Framework look like? 4 Zachman Framework benefits 6 Project scope definition 7 Checking project completeness 7 A learning tool 8 Zachman Framework & MEGA 9 MEGA Zachman Portal 11 MEGA Concepts mapping 12 Annexes 22 Annex A -Customization samples 22 Annex B - Usual definition of the Zachman Framework cells 24 Introduction This document positions MEGA Suite™ against the very famous Zachman Framework™. It provides a summary of what the Zachman Framework™ is and how the MEGA Suite is related to this framework. This document includes information from Internet sources, including John Zachman website. MEGA & Zachman page 2
  • 3. What is the Zachman Framework? The Enterprise Architecture Framework (EA) frequently called the Zachman Framework, introduced in 1987 by John Zachman and extended by Sowa in 1992 (Sowa and Zachman 1992), as it applies to enterprises is a logical structure for classifying and organizing the descriptive representations of an enterprise that are significant to the management of the enterprise as well as to the development of the enterprise’s systems. It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g., buildings or airplanes.) The units of the Framework can also be understood as organization scheme for all kinds of metadata involved in building and using an information system and have therefore become widely rec ognized during the last years. This Framework is intended being neutral in the sense that it’s defined totally independents from tools or methodologies and therefore any tool or any methodology can be mapped against it to understand what they are doing, and what they are NOT doing. The Zachman Framework cannot be considered as either a modeling language, or a methodology, or a modeling notation. MEGA & Zachman page 3
  • 4. What does the Zachman Framework look like? The Zachman Framework appears as a matrix containing 30 cells, each of them focusing on one dimension or perspective of the enterprise. Rows are often presented as levels of abstraction involved in the systems development process, while columns represent different perspectives also involved in the cycle. However, these rows, really, are different dimensions, each one being candidate to some decomposition and realization layers, handling various levels of abstraction. Zachman and his followers established a set of rules for interpreting and using the original framework (see Bruce, 1992). These may be summarized as follows. • Rule 1: The columns have no ordering. No one is more important than another but focusing on one may have significant practical implications. • Rule 2: Each column represents a unique model. MEGA & Zachman page 4
  • 5. • Rule 3: Each column is unique although they are interconnected. • Rule 4: Each row represents a unique perspective. • Rule 5: Therefore, each cell is unique (no item should show up in more than one cell). • Rule 6: Each row is a complete model from the row's perspective. • Rule 7: The logic is recursive and generic. MEGA & Zachman page 5
  • 6. Zachman Framework benefits “There are four reasons why you do Architecture: "Alignment," "Integration," "Change," and "Reduced Time-to-Market." • Do you care that the systems I/S is producing actually are aligned with Management's requirements and warrant the expenditure of funds allocated to I/S? • Do you care whether the data in the Enterprise means the same thing to anyone who uses it, that messages can be cost-effectively transmitted and received whatever time of day or night or day of the year, and that business rules can be uniformly enforced throughout the Enterprise? • Do you care whether changes to the Enterprise can be made with minimum time, disruption, and cost? • Do you care whether I/S can produce "custom" implementations on demand, reducing their time-to-market to virtually zero? If you care about any or all of these things, YOU ARE GOING TO DO ARCHITECTURE, because without Architecture, you cannot do ANY of these things.” Architecture is an asset. You can save orders of magnitude more money and time, but you have to invest in Architecture to enable you to do something you otherwise are unable to do, namely: "Alignment," "Integration," "Change," and "Mass Customization." John Zachman Modeling techniques are the best way to efficiently manage enterprise assets. Powerful modeling approaches require a large range of modeling artifacts to be able to cover the entire scope of enterprise architecture. But, it is not always easy to know which modeling technique to use. The most common question asked by Business and IT architects when using modeling is: “where should I start from?”. And the usual answer is that there is no one starting point; it has to be defined on a project basis. This statement usually adds more confusion than it really brings any helps to modelers. The Zachman Framework is a powerful answer to these questions: by providing a global view of the multiple aspects of enterprise architecture, it offers a navigation tool that acts both as starter and a compass for enterprise modelers. It provides a context in which Business and IT architects can build a flexible, consistent information system, according to the strategy of their enterprise. MEGA & Zachman page 6
  • 7. The Zachman framework can successfully be used as a tool for defining project scope, for checking project completeness, and as a learning tool for enterprise architecture. Project scope definition Most projects do not need to cover all enterprise analysis dimensions. The Zachman framework helps business analysts and system architects organize their thoughts about architecture and guides them to narrow the scope of the modeling artifacts required to carry out their projects. It is then easier to tackle the “where to start” question and to define a methodology path tailored to the project needs. For instance, rows in the framework identify types of stakeholders and the associated detail of information they require. Detailed SQL data types are not the right modeling artifact if the objectives is to build a map of core business objects. Checking project completeness Another difficult question to answer is whether any significant element was left out of the project scope. The Zachman Framework ensures all appropriate aspects are addressed or used as a discussion support tool. For instance, geographical location issues might be crucial for the project and must be analyzed at all levels of the abstraction stack: business process, IT systems, distributed objects. MEGA & Zachman page 7
  • 8. A learning tool As enterprise architects get more familiar with enterprise modeling, they discover the benefits of having multiple dimensions for enterprise projects and how methodology steps can used to move from one cell to another. Model driven approach can be better enforced within project and increase their success factors. MEGA & Zachman page 8
  • 9. Zachman Framework & MEGA MEGA Suite™ is a comprehensive suite of modeling products covering the entire scope of enterprise architecture. All products are natively integrated and operate with MEGA Repository. MEGA Repository is the heart of MEGA software providing share, storage, administration, reporting and security functions. MEGA Process provides capability to capture, optimize and document business processes. Mega Architecture enables users to produce functional views of their IT architecture in alignment with business process definitions. MEGA Integration, .Mega Development and Mega Database are used to produce IT system specifications for systems, workflows, components and databases in order to efficiently drive project development. Thanks to MEGA Repository all products automate accurate documentation and web site publishing to share information inside and outside project teams and provide the backbone for enterprise architecture frameworks. MEGA & Zachman page 9
  • 10. MEGA Suite™ provides, out of the box, a complete answer for 24 cells out of 30 listed in the Zachman Framework. According to Zachman, supporting the framework is not about providing the same kind of model with different level of detail for each cell: “The Rows are different, that is, different models occur in every Row within any one Column. It is just like in classic building architecture... “The models are RELATED to one another, but they are not the SAME model just in increasing levels of detail. ” John Zachman Each product of MEGA Suite MEGA Suite provides the appropriate set of models and the relationships between each model for the different cells. This powerful interconnection between key concepts increases the added value brought by the enterprise model. A detail specification for each cell and model mapping is given at the end of this document: MEGA Concepts mapping MEGA & Zachman page 10
  • 11. MEGA Zachman Portal MEGA Suite™ comes with an HTML service that acts as a Zachman Portal onto the repository. For each Zachman cell, a mapping window is provided that describes the concept used in MEGA, along with a query that selects the corresponding model objects in the current repository. Thereby, users can easily discover best modeling practices in MEGA with the standard guidelines provided by the Zachman Framework. MEGA & Zachman page 11
  • 12. The Zachman portal is implemented as simple HTML pages with very straightforward scripting API invoking queries onto the repository. It can be used as a basis to create new portals or to adapt the Zachman framework to enterprise specific requirements. MEGA Concepts mapping The following paragraphs provide a detailed mapping between Zachman cells and concept s as utilized in MEGA. Z a c hma n cel l Row 1 – Co lum n 1 Cont ext ual / Data: T hings Imp or ta nt for th e b usin es s Concept Cont ents r es ulti ng fr om cor e Busi n ess Pr oces se s a nd d eli ver ed to Exter nal ma ppin g Entit ie s (Cust omer s). Busi ne ss C las s a ss ociate d to C o nte nts deli ver ed by Bu si ne ss Pr oces se s Produc t MEGA Pr oce ss R a tiona le Captur e e nter pr is e mai n del iv er able s a nd t h eir a sso ciat ed bu si ne ss obj ect s. Z a c hma n cel l R ow 1 – Co lumn 2 List of proc esses the busi ness p erforms Concept Busi ne ss Pr oc es s: ma ppin g Produc t MEGA Pr oce ss R a tiona le Ide ntify t he e nter pr i se m ai n v al ue ch ai ns. Th er e are us ually at most 3 or 5 cor e busi ne ss pr oc ess es i n a n e nter pr is e MEGA & Zachman page 12
  • 13. Zac hma n cell R ow 1 – Co lumn 3 List of lo cati on wher e th e b usi n es s oper at es Con ce pt Sit e: A site is the ge ogr ap hical lo cati on of a n or gan izat io n mapping Pr oduct MEGA Pr oce ss Rati on ale Ide ntify t he imp act of ge ogr ap hi cal di strib ution i n proc es s a naly sis Z a c hma n cel l R ow 1 – Co lumn 4 List of or ga nizat iona l uni ts Concept Exter n al E ntitie s: Org- Un it of ty pe Exter n al ma ppin g Or g- Unit wit h ster e oty p e Str uctur e, M an ag er Produc t MEGA Pr oce ss R a tiona le Analy z e c ust omer segm e ntati on acc or ding t o pr odu ct d el iver y Ide ntify ma in or ga nizati on u nits Z a c hma n cel l R ow 1 – Co lumn 5 List of Even ts si gnif ica nt to t he bus iness Concept Me ssa ge tr ig ger i ng Cor e Bu si ne ss Pr oc es se s ma ppin g Produc t MEGA Pr oce ss R a tiona le Und er sta nd how a nd w he n t he e nv ir onme nt i nter a ct wit h the e nter pr ise MEGA & Zachman page 13
  • 14. Z a c hma n cel l R ow 1 – Co lumn 6 List of bus iness goa ls/st ra tegie s Concept Object ive a ss oci ate d to glo bal r equir ement di agr ams ma ppin g Produc t All Pr o du cts R a tiona le Ide ntify c or porat e obj ecti ves ar e dr i ver s f or bot h bu si ne ss an d IT pr oj ect s Z a c hma n cel l R ow 2 – Co lumn 1 Sema nt ic M odel Concept Pack age Dat a Mo de ls asso ciated wit h Busi n ess Pr oc es se s or Busi ne ss ma ppin g Fun cti ons Produc t MEGA Dat abase R a tiona le Defin e t he data sc op e r e quir ed i n t he co ntext of a B usi ne ss Pr oc es s or a Busi ne ss Fu ncti on . Busi ne ss data mod el s e na ble d ata r e sp onsib ility m an agem ent. Busi ne ss obj ect s ca n be r e us ed amo ng multi pl e d ata mo de ls MEGA & Zachman page 14
  • 15. Z a c hma n cel l R ow 2 – Co lumn 2 Busin ess Proc ess M odel Concept Busi ne ss Pr oc es s Defi nit io n Di agr am ma ppin g Produc t MEGA Pr oce ss R a tiona le Descr i be b us in es s pr oc ess va lue ch ai ns i n ter m of acti vities a nd t heir seq ue ncin g. Act iv ities ar e st ep s i n a busi ne ss pr oc ess a nd d efin e w hat is to be done in t h e pr oce ss in de pe nd e ntly of a ny or g an izat ional conc er n. Thi s comm o n d efinitio n i s u se d as a r efer e nc e for all spec ific pr o ce ss impl ementat ions Z a c hma n cel l R ow 2 – Co lumn 3 Busin ess Lo gi stic s Syste m Concept Busi ne ss Pr oc es s / Sit e ma ppin g Produc t MEGA Pr oce ss R a tiona le Prov id e a map of geogr aphi cal site and d escr i be geo gr aphic al dep loym ent for bus ines s pro ce ss es. MEGA & Zachman page 15
  • 16. Z a c hma n cel l R ow 2 – Co lumn 4 Orga n iza tion c ha rt: role, sk il l s ets, sec ur ity issues Concept Or gani zati on al c har t ma ppin g Proc edur e Produc t MEGA Pr oce ss R a tiona le Prov id e an over v ie w of the e nter pr is e str uct ur e. Or g- c har ts in dicate t he hier ar chy of Or g- Unit s in t he e nt er pr ise, sp ecifie s th e Per so ns that pl ay the r ole of th es e Or g- Unit s, a nd s ho ws at whic h Sit e t he Or g- Un it i s l ocat ed Descr i be t he impl eme ntat io n of a ll or par t of a B usi ne ss Pr oc es s fr om an organ izat io n vie wp oint. Z a c hma n cel l R ow 2 – Co lumn 5 M a ster Schedu le Concept Coll aborat io n d efi niti o n ma ppin g Produc t MEGA Pr oce ss, MEGA Arc hit ect ur e or MEGA Int egr at ion R a tiona le Rel ate bu si ness ev ents t o th eir bus in es s re su lts i nc ludi ng tim in g a nd seq ue ncin g r ules MEGA & Zachman page 16
  • 17. Z a c hma n cel l R ow 2 – Co lumn 6 Busin ess Pla n Concept Object ives an d c ontri but in g Pr oj ect s ma ppin g Produc t All M EGA pr oduct s R a tiona le Defin e the plan, in t er m of pr oje ct, for rea liz ati on of c or por at e o bje cti ve s Z a c hma n cel l R ow 3 – Co lumn 1 Logic a l Da ta Mode l Concept Data M od el s as so ciated t o Dat abase s ma ppin g Produc t MEGA Dat abase R a tiona le Defin e the r u les for data ma na geme nt and data stor age. Z a c hma n cel l R ow 3 – Co lumn 2 Applic a t ion Archi tec tur e Concept Appl icatio n Arch ite ctur e Diagr am ma ppin g Produc t MEGA Ar c hite ctur e R a tiona le Descr i be th e softwar e e n vir o nment f or an appl icat io n, a sit e, an Or g-U nit, or for the e ntire compa ny . MEGA & Zachman page 17
  • 18. Z a c hma n cel l R ow 3 – Co lumn 3 Distr ibut ed Syst em Arc h itec t ure Concept Tec h nical Ar chit ectur e Diagr am ma ppin g Produc t MEGA Ar c hite ctur e R a tiona le Descr i be E nter pr i se Ar c hit ectur e deploy m ent e xpr e ss ed i n ter m of site, ser v er s, net work, no de s, ... Z a c hma n cel l R ow 3 – Co lumn 4 Huma n Interfa ce Arch itec ture Concept Cr oss r ef er e nce b etwee n b us in es s ta sks an d sy stem r eso ur ce s ma ppin g Produc t MEGA Pr oce ss an d MEGA Ar c hit ectur e R a tiona le Ide ntify i nt er acti on po int s bet we en Or g- U nits a nd sy stem r es ourc es Z a c hma n cel l R ow 3 – Co lumn 5 Proc essing Struc ture Concept Busi ne ss O bje ct St ate Ma chin e ma ppin g Produc t MEGA Pr oce ss an d MEGA De v elo pment R a tiona le Defin e th e tr an siti on cy c le for busi ne ss o bje cts i n r elat io nshi p wit h bu si ne ss event s MEGA & Zachman page 18
  • 19. Z a c hma n cel l R ow 3 – Co lumn 6 Busin ess Ru le Mode l Concept Req uir eme nts an d their c o nstr ai ned object s ma ppin g Produc t All M EGA Pr odu cts R a tiona le Mod el ent erpr is e b us in es s r ule s in ter m of th eir i nte nts (obje cti ve s/r e quir eme nts) an d th e me ans of ha vi ng the r e su lti ng c on strai nts (con str ai ne d busi n es s pr o cess / r ea liz in g pr o cedur e). Z a c hma n cel l R ow 4 – Co lumn 1 Physic a l Da ta Model Concept Rel atio na l M od el s a nd X ML mo de ls ma ppin g Produc t MEGA Dat abase or MEGA I ntegr at io n R a tiona le Mod el th e p hysi cal repr e sentat io n of e nter pr i se bu sine ss data Z a c hma n cel l R ow 4 – Co lumn 2 System Des ig n Concept System Ar ch itect ur e D iagr am ma ppin g Wor kflow dia gr ams Compo nent diagr ams Produc t MEGA I nt egrati on or MEGA Deve lopme nt R a tiona le Desi gn enter pri se sy st ems an d compo n ent s MEGA & Zachman page 19
  • 20. Z a c hma n cel l R ow 4 – Co lumn 3 Technology Syste m Arc hi tec ture Concept Detai le d T ec hn ica l Ar ch itectur e Diagr am s ma ppin g Compo nent Dep loy ment Diagr ams Produc t MEGA Ar c hite ctur e or M EGA De ve lo pme nt R a tiona le Descr i be t h e ent er pris e p hys ica l te ch nology e nvir onme nt sho wi ng t he act ual har d ware an d sy st em softwar e at th e n odes an d l in es of th eir sy stem s. Z a c hma n cel l R ow 4 – Co lumn 4 Presenta tion Arc hi tectur e Concept User I nter fa ces a nd User I nt er face D iagr am s ma ppin g Produc t MEGA I nt egrati on R a tiona le Specify er go nomi c r eq uir eme nt and pr ese ntatio n format Z a c hma n cel l R ow 5 – Co lumn 1 Da ta Def ini tion Concept Gen er ate d SQL scr ipt or XML schem a ma ppin g Produc t MEGA Dat abase an d MEGA I ntegr ati on R a tiona le Prov id e automatic ally data defi nit io n immedi ately a vai lab le for data ba se mana gers an d d ev el op er s. MEGA & Zachman page 20
  • 21. Z a c hma n cel l R ow 5 – Co lumn 2 Progra ms Concept Gen er ate d s our c e c od e or WML w or kflo w d efi niti on ma ppin g Produc t MEGA I nt egrati on an d M EGA De v elopme nt R a tiona le Prov id e aut omati cally sour c e co de an d wor kfl ow e xecuta bl e scr i pts to devel opme nt te ams MEGA & Zachman page 21
  • 22. Annexes Annex A -Customization samples Treasury Enterprise Architecture MEGA & Zachman page 22
  • 23. Healthcare Informatics Framework MEGA & Zachman page 23
  • 24. Annex B - Usual definition of the Zachman Framework cells The rows represent various abstraction levels typically involved in the systems development process, while columns represent different perspectives also involved in the cycle. 1. Scope (Ballpark view): Definition of the enterprise's direction and business purpose. This is necessary to establish the context for any system development effort. 2. Model of the business (Owner's view): This defines — in business terms — the nature of the business, including its structure, functions, organization, and so forth. 3. Model of the information system (Architect's view): This defines the business described in step 2, but in more rigorous information terms. Where row two described business functions, for example, as perceived by the people performing them, row three describes them specifically as transformations of data. Where row two described all the things of interest to the enterprise, row three describes those things about which the organization wishes to collect and maintain information, and begins to describe that information. 4. Technology model (Designer's view): This describes how technology may be used to address the information processing needs identified in the previous rows. Here relational databases are chosen over network ones (or vice versa), kinds of languages are selected and program structures are defined, user interfaces are described, and so forth. 5. Detailed representations (Builder's view): Here a particular language is chosen, and the program listings, database specifications, networks, and so forth are all produced. 6. Functioning system: Finally, a system is implemented and made part of an organization. The columns in the Zachman framework represent different areas of interest for each perspective. The columns describe the dimensions of the systems development effort. As shown in Figure 2, these are: 1. Data: Each of the rows in this column address understanding of and dealing with an enterprise's data. This begins in row one with a list of the things that concern the company and affect its direction and purpose. Row two, is a contiguous model of the things seen by the participants in the business. Many-to-many and n-ary relationships may be present; reflecting the way the business views them. Also, relationships may be shown which themselves MEGA & Zachman page 24
  • 25. have attributes. Row three provides more of an information-based perspective, resolving many -to-many and n-ary relationships, along with relationships containing their own attributes. Indeed, attributes are more exhaustively defined, and unique identifiers are specified. Entities are generalized to more closely reflect the underlying structure of the business and its relationships. In row four, entities are converted to table definitions, object classes, hi erarchy segments, or whatever is appropriate for the kind of data base management system to be used. This is tantamount to creating the data definition language statements. In row five, the tables are actually implemented on physical disk drives, using the underlying organization of the database management system. This is where table spaces are defined, disk packs are allocated, and so forth. The actual database itself is created and initial data are converted and loaded for row six. 2. Function: The rows in the function column describe the process of translating the mission of the enterprise into successively more detailed definitions of its operations. Where row one is a list of the kinds of activities the enterprise conducts, row two describes these activities in a contiguous model. Row three portrays them in terms of data transforming processes, described exclusively in terms of the conversion of input data into output data. The technology model in row four then converts these data conversion processes into the definition of program modules and how they interact with each other. Pseudo-code is produced here. Row five then converts these into source and object code. Row six is where the code is linked and converted to executable programs. Note that in the object- oriented approach, functions and data tend to be addressed together. 3. Network: This column is concerned with the geographical distribution of the enterprise's activities. At the strategic level (row one), this is simply a listing of the places where the enterprise does business. At row two, this becomes a more detailed communications chart, describing how the various locations interact with each other. Row three produces the architecture for data distribution, itemizing what information is created where and where it is to be used. In row four, this distribution is translated into the kinds of computer facilities that are required in each location, and in row five, these facilities requirements are translated into specification of particular computers, protocols, communications facilities, and the like. Row six describes the implemented communications facilities. 4. People: The fourth column describes who is involved in the business and in the introduction of new technology. The row one model of people is a simple list of the organizational units and each unit's mission. In row two, this list is fleshed out into a full organization chart, linked to the function column. Here also, requirements for security are described in general terms. In row MEGA & Zachman page 25
  • 26. three, the potential interaction between people and technology begins to be specified, specifically in terms of who needs what information to do his job. What roles do each play and what data are necessary for those roles? Along with this are specific definitions of security requirements, in terms of who (which role) is permitted access to what. In row four, the actual interface between each person and the technology is designed. In this row, issues of interface graphics, navigation paths, security rules and presentation style are addressed. In row five, this design is converted into the outward appearance of each program, as well as the definitions of access permissions in terms of specific tables and/or columns each user can have access to. In row six, you have trained people, using the new system. 5. Time: The fifth column describes the effects of time on the enterprise. It is difficult to describe or address this column in isolation from the others, especially column two. At the strategic (row one) level, this is a description of the business cycle and overall business events. In the detailed model of the business (row two), the time column defines when functions are to happen and under what circumstances. Row three defines the business events, which cause specific data transformations and entity state changes to take place. In the technology model (row four), the events become program triggers and messages, and the information processing responses are designed in detail. In row five, these designs become specific programs. In row six business events are correctly responded to by the system. 6. Motivation: As Mr. Zachman describes it; this is concerned with the translation of business goals and strategies into specific ends and means. This can be expanded to include the entire set of constraints that apply to an enterprise's efforts. In row one, the enterprise identifies its goals and strategies in general, common language terms. In row two, these are translated into the specific rules and constraints that apply to an enterprise's operation. In row three, business rules may be expressed in terms of information that is and is not permitted to exist. This includes constraints on the creation of rows in a database as well as on the updating of specific values. In row four, these business rules will be converted to program design elements, and in row five they will become specific programs. In row six, business rules are enforced. MEGA & Zachman page 26