Your SlideShare is downloading. ×
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Enterprise Architectures – Survey of Practices and Initiatives
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enterprise Architectures – Survey of Practices and Initiatives

630

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
630
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Enterprise Architectures – Survey of Practices and Initiatives Frank Lillehagen and Dag Karlsen Computas AS, Norway, fli@computas.com and dk@computas.com ABSTRACT: This paper presents an overview of current practices and development initiatives in the field of Enterprise Architecture, focusing on their underlying concepts and principles. The paper gives a brief historic overview of the field, followed by a description of ongoing initiatives to transform from enterprise architec- ture methodologies used by consultants and managers to architectures that also guide and support new ways of developing, executing and managing computing solutions. To conclude the paper presents an outline of existing architecting research approaches, and draws some pre- liminary conclusions. Based on this survey, some recommendations for future research are discussed. 1 INTRODUCTION businesses today. However, architecture frame- works still have a focus on the information aspects Enterprise architectures are developed for more of the business and little if any treatment of the efficient operations of a business venture. Enter- knowledge aspects. prise architecture models are developed to give busi- ness managers a better understanding of the things 1.2 Context the enterprise owns, operates, and produces so they Enterprise architecture (EA) is a simplified and ag- can make better business decisions. Likewise, in- gregated representation of the basic structure and or- dustrial and military planners need architecture mod- ganisation of the enterprise. It is a plan which shows els so they can understand what they have, what they the main features and characteristics of the enter- don’t have, and what capabilities they need to have prise and its assets that are to be analysed, justified to fill the gaps. This information is used to make and agreed before the detailed technical design. It is better decisions about which capabilities to develop shared and discussed enterprise-wide at a high level with limited budgets. The features and functions to of abstraction between all stakeholders. be provided by hardware and software systems are In the current industrial and economic context, often described in architecture models in such a way enterprise systems need to be constantly and that the proposed systems can be evaluated for how smoothly re-engineered to respond to changing mar- much they contribute to increased effectiveness of ket demand and technological evolution. Enterprise business and war-fighting operations. architecture, considered as the foundation of enter- prise systems, has emerged as a ‘tool’ to help stake- 1.1 Background holders to manage system engineering and changes. Enterprise architectures gained popularity when It is not only an IT issue, but also strategy, business John Zachman developed his framework for dealing and knowledge ones. with large information systems. [Zachman87] These frameworks originally focused on data processing 1.3 Practises using mainframe computers, so their emphasis was on the data aspects of a business. Later there was an Enterprise architecture, as an integrating enterprise emphasis on information processing in the business concept is today developed and delivered as meth- (during the so-called Information Age). In the past odology models. For decades, shipbuilding and con- decade there has been an increasing interest in struction industry have used architecture in the de- “knowledge management” and services, since it has sign and construction of their product families. Their been recognized as a key ingredient in the success of “architecture” utilizes standard symbols that can be 1
  • 2. recognized and understood by all members of their (target) EA is to maximize a set of business goals industry for carrying out detailed design, construc- and objectives given a set of constraints, conditions, tion and engineering work. and challenges. The purpose of an "as-is" architec- The enterprise engineering community by com- ture (baseline) is to document the current arrange- parison has never had the advantage of this type of ment such that a transition to the desired target state “time tested” structure. Instead, since the beginning, can be determined. Furthermore, the baseline could many heterogenous architecture proposals have been have been optimized for a prior set of constraints, developed. They are often overlapping approaches conditions, and challenges and any changes to these and the underlying concepts are not explicitly de- usually demand a change to the current architecture. fined. Different architecture description languages are not interoperable between them. These languages 2.1.2 Enterprise architecture as a ‘skeleton’ are either too detailed or lack expressive significance Independently of business goals or strategies, EA is, to represent system features. Similarities and differ- first of all, the foundation of enterprise systems. Ac- ences between architectures can not be perceived by cording to ISO 15704 (2000), an architecture is a de- users; and this creates obstacles for its correct under- scription of the basic arrangement and connectivity standing in industry and finally its acceptance and of parts of a system (either a physical or a concep- use. The lack of a generally agreed terminology and tual object or entity). The software community also semantically enriched knowledge corpus in this do- considers that architecture is the fundamental or- main is also a bottleneck for its efficient application. ganization of a system embodied in its components, their relationships to each other and to the environ- ment and the principles guiding its design and evolu- 2 ARCHITECTURAL PRACTICES tion (IEEE 1471, 2000). Specifically, software archi- tecture is ‘a set of software components, externally 2.1 What is an enterprise architecture visible properties of those components, and relation- ships among them’ (Florijn, 2002). More generally Giving a precise and concise definition on Enterprise an architecture must: Architecture (EA) is challenging. Confronting to the - have properties that can be verified with respect demand of customers, James Martin (2004) lists the to user needs (ex. open or closed architecture, inter- following requirements to define EA: (1) must be operable or not, centralised or decentralised…). one sentence; (2) may elaborate from that single sen- - be simple so that business people can easily un- tence to make certain clarifications; (3) must be un- derstand, check, analyse, discuss as a ‘language’ derstandable by executives; (4) must be useful to shared at corporate level. those who will develop the EA; (5) must be applica- - have a style (by comparison with construction ble to a government organization; (6) must be put where architecture can represent some particular into context of baseline and target EAs; and (7) must characteristics of a building such as ‘gothic’, ‘ro- provide the executives with the proper expectations maine’…). EA should be able to characterise enter- of what can be delivered to them and what they can prise systems (ex. ‘fractal’, ‘holonic’, or ‘agile’...). use it for. Usually, architecture has various meanings de- pending on its contextual usage (Open Group, 2.2 Enterprise architecture methodologies 2000): (1) A formal description of a system at com- ISO 15704 (2000) has considered that there are two ponent level to guide its implementation; (2) The and only two types of architectures that deal with en- structure of components, their interrelationships, and terprise integration: the principles and guidelines governing their design System architectures (sometimes referred to as and evolution over time; (3) Organizational structure "type 1" architectures) that deal with the design of a of a system or component. system, e.g. the system part of an overall enterprise Generally speaking, EA should be organized in a integration; way that supports reasoning about the structural Enterprise-reference projects (sometimes referred properties of the system. It defines the components to as "type 2" architectures) that deal with the or- that make up the overall system, and provides a plan ganisation of the development and implementation from which the system can be developed. of a project such as an enterprise integration or other enterprise development programme. 2.1.1 Enterprise architecture vs. business objectives In other words, type 1 architecture represents sys- EA does not start with technology, but a strategic tem or sub-system in terms of its structure and be- framework, the vision, goals, and priority business haviours. The type 2 architecture is actually frame- activities. According to James Martin (2004), an EA work aiming at structuring activities/tasks necessary is a specific arrangement of business objectives, fea- to design and build a system. For example, Zach- tures and functions. The purpose of a "should-be" man’s architecture is type 2 architecture.
  • 3. that are going to be made in reconciling the poten- Some other works make distinction between concep- tially conflicting concerns of different stakeholders. tual and technical architectures. The conceptual ar- Without the architecture, it is highly unlikely that all chitecture is derived from business requirements; the concerns and requirements will be considered and are understood and supported by senior man- and met (Open Group, 2000). agement. The technical architecture provides the technical components that enable the business 2.3.2 Enterprise architecture as a ‘blueprint’ strategies and functions. Like in construction, EA allows to create a vision of Sometimes conceptual architecture is also called the future system. This vision is represented as a functional or business architecture; and technical ar- high level solution structure (Florijn, 2002) that lays chitecture, ICT architecture. TOGAF (Open Group, down the foundation for design. It is a kind of 2000) considers four types of architecture which are ‘skeleton’ focusing on essential features and charac- subsets of EA: Business architecture, Information teristics of the system. Forces and weakness can be Technology architecture, Data/information architec- then more easily detected and analysed. ture; and Application (systems) architecture. Considering architecture as a high level solution Lillehagen et al. (2002) advanced the concept of is remarkable. Usually engineering design is divided ‘knowledge architecture’. Separation between busi- in preliminary and detailed designs. Preliminary de- ness, knowledge and ICT architectures should be sign is also called architecture design. During the seen as a design principle (Tinella, 2003). preliminary design phase, only solution types are de- fined. For example, ‘prefer matrix organisation than In software engineering, EA is viewed in a different hierarchical one’; ‘privilege wireless network than way. Malan (2002-b) mentioned three types of archi- cabled one’, etc. Working on high level solution also tectures: (1) conceptual architecture (identification facilitates the use of deign principles which is an- of components and allocation of responsibilities to other adjacent research subject. them); (2) logical architecture (design of component interactions, connection mechanisms and protocols; interface design and specification…); (3) execution 2.4 Some tentative clarifications architecture (assignment of the runtime component instances to processes; how physical resources are 2.4.1 Architecture vs. infrastructure allocated to them). In some other approaches for ex- An infrastructure is not architecture; an infrastruc- ample (IEEE 1471), enterprise architecture is seen as ture is a system which may have architecture. At the a complementary architecture to software architec- origin, the concept ‘infrastructure’ is used in urban ture, to document system-wide organisation and engineering referring to some common services of a business context in which software operate. city. For example, water supplies, electricity net- work, transport, etc. Similarly, Enterprise infrastruc- 2.3 The benefits of enterprise architecture ture is a set of services common to all enterprise ac- tivities such as ‘information exchange, data storage, The concept of architecture is closely related to en- communication services, local area network, etc. gineering. There should be significant difference be- Ring (2003) also considered that ‘An infrastruc- tween a system built with architecture and one with- ture provides such common functions such as; a) en- out. Architecture allows managing complexity and suring the location of modules within whatever co- risks due to various factors such as technology, size, ordinate system is pertinent, b) providing access or interface, context and stakeholders. Design large interconnection, c) providing isolation, and d) ensur- scale systems (like enterprise) requires high level ing stability throughout a dynamic scenario of traf- abstractions. It means we need a mechanism to allow fic, wear, contextual changes and internal innova- organising enterprise system at sub-system and tions’. module levels. Separation between EA and infrastructure is de- sirable. When EA evolves as business changes, the 2.3.1 Architecture vs. stakeholders expectations infrastructure should not be re-engineered every EA at high level of abstraction is a means of com- time. On the other hand, when technology evolves, munication with and among stakeholders. It allows new services can be implemented without the neces- representing stakeholder’s expectations in terms of sity to modify the enterprise architecture. features of enterprise system rather than document- ing detailed requirements on functions, data or re- 2.4.2 Architecture vs. architectural framework sources that will be specified in the later stage. The term ‘architectural framework’ is a different The role of the architect is to address concerns, concept from system architecture. In (CIO, 1999), an show how the concerns and the requirements are go- architecture framework is defined as an organizing ing to be addressed, and by showing the trade-offs mechanism for managing the development and 3
  • 4. maintenance of architecture descriptions. TOGAF (c) TOGAF (Open Group, 2000) also considers architectural (d) SIMA framework as a tool to use for developing a broad (e) San Francisco range of different architectures. (f) CORBA The framework contains: (1) a method for design- (g) Federal Enterprise ing a system in terms of a set of building blocks, and (h) Treasury Enterprise for showing how the building blocks fit together; (2) (i) C4ISR a set of tools and a common vocabulary; (3) a list of (j) Archimate recommended standards and compliant products to implement the building blocks. A new framework was in 2003 developed by the The term ‘architectural framework’ is also close US Department of Defense called the DOD Archi- to another adjacent concept which is ‘modelling tecture Framework [Dodaf04]. DODAF is an evolu- framework’, for example the CIMOSA modelling tionary upgrade of the C4ISR Architecture Frame- framework is type 2 architecture. work both of which prescribe three views of the architecture: Operational, Technical and Systems. 2.4.3 Enterprise architecture vs. enterprise model Another adjacent concept to EA is enterprise model 3.1 The DoDAF Framework (EM). EM describes the EA from various viewpoints in detail to allow specifying and implementing the Architecture products are graphical, textual, and systems. EA is not executive entity, but an enterprise tabular views that are developed in the course of model can be. building a particular architecture description. DO- In other words, the focus of EA and enterprise DAF is composed of three main views as depucted model is different. EA amplifies significant charac- in the figure below. teristics or features of a system; while enterprise model describes and specifies the system. Lillehagen (2002) considers that an enterprise model will have an Enterprise Architecture, and En- terprise modelling languages have meta-models that are components of the EA at the knowledge layer. 2.5 Distinguish architectural decisions Another adjacent subject is architectural decisions i.e. decisions to take to arrange architecture in this way rather than that way. Architectural decisions are those that must be made from an overall system per- spective. According Bass (1997), those decisions DODAF specifies 26 standard products to be identify the system’s key structural elements, and used to develop architecture descriptions with a their relationships, and they define how to achieve common approach. The products are shown in the significantly architectural requirements. Indeed, en- table below. terprise engineering involves many decisions, some View Framework are architectural, and most of them are not. The ra- Type Product Framework Product Name All AV-1 Overview and Summary Information tionale is to show how the decisions are architec- Views AV-2 Integrated Dictionary tural. Malan (2002-a) points out that if you can OV-1 Operational High-Level Operational Concept Graphic OV-2 Operational Node Connectivity Description achieve the requirement by deferring the decision to OV-3 Operational Information Exchange Matrix OV-4 Organizational Relationships Chart a lower level, it is not architecturally significant, and OV-5 Operational Activity Model the decision is not an architectural one. OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event-Trace Description OV-7 Logical Data Model SV-1 Systems Interface Description 3 ARCHITECTURE FRAMEWORKS SV-2 Systems Communications Description SV-3 Systems-Systems Matrix SV-4 Systems Functionality Description There are many architecture frameworks avail- Systems SV-5 Operational Activity to Systems Function Traceability Matrix SV-6 Systems Data Exchange Matrix able to assist the architects in doing their work [Mar- SV-7 Systems Performance Parameters Matrix tin 2004]: SV-8 SV-9 Systems Evolution Description Systems Technology Forecast SV-10a Systems Rules Model SV-10b Systems State Transition Description (a) Zachman SV-10c Systems Event-Trace Description (b) Gartner Group SV-11 TV-1 Physical Schema Technical Standards Profile Tech- nical TV-2 Technical Standards Forecast
  • 5. The major products in DODAF are related to Now a relevant question to ask is what extent of each other through a set of simple relationships. A “knowledge modeling” is addressed by these change on any product can propagate to other prod- frameworks. The result of several analysis is that ucts. It is important to maintain all products in such none of them support active knowledge modeling, a way so that they are all consistent with each other. that is they are all collections of static information views. They are offline methodologies with no direct 3.2 The AFEAF Framework connection to systems execution or business or field operations. The US Air Force has recently developed an en- terprise architecture framework [AFEAF] to bridge the gap between DODAF and FEAF. The AFEAF 4 ARCHITECTURAL APPROACHES has three levels (or “perspectives”): Architecture Reference Models level, Mission Area and Cross- Mission Area level, and Program and Node level. 4.1 Architectures for enterprise integration) These three perspectives are illustrated below along The architecture frameworks are concerned with with how the DODAF and FEAF map into these concepts and principles for integrated enterprise levels. modelling and engineering. They do not deal with Relevant Relevant Reference the representation of how an enterprise is structured Architecture Frameworks AF Enterprise Architecture Descriptions Models & Views or operated. In other words, they do not represent Federal Architecture Perspectives Architecture Perspectives processes, data, organisation etc. Rather, they define Enterprise Architecture Air Force Five Reference Models the key concepts that are necessary to describe en- Framework (FEAF) Architecture Reference Models (Adapted from FEAF) terprise systems so that models built are consistent and easily integrated across stakeholders. Operational View Mission Area & Cross Mission Area Architecture Views & Products Architecture Views & DOD Products Technical View 4.1.1 Early architectural initiatives Architecture System View Framework (DODAF) During 80’s, research were carried out in Europe and Program & Node Architecture Views & Products Architecture Views & U.S.A. to develop enterprise architectures. Among Products them the most known: the Purdue Enterprise- Reference Architecture (PERA) (Williams 1991), The most commonly known framework for enter- the GIM architecture (Chen and Doumeingts, 1996), prise modeling is the Zachman Framework for in- the Computer Integrated Manufacturing Open Sys- formation systems. [Zachman87, Zachman92, tem Architecture (CIMOSA) (Amice 1993) etc. Cook96] The framework is a matrix consisting of These architectures are mainly developed along the six columns and five rows. The columns represent system life cycle to show what must be done to the six interrogatives of What (data), How (func- model, design and implement an integrated enter- tion), Where (network), Who (people), When prise system. (time), and Why (motivation). The rows represent The Zachman architecture is another example of the five perspectives of the Planner, Owner, De- these initiatives. It structures various enterprise signer, Builder, and Subcontractor. modelling and engineering concepts according to The Federal Enterprise Architecture Framework ‘the perspectives of various stakeholders involved in provides “an organized structure and a collection of the enterprise engineering effort. This is because dif- common terms by which Federal segments can inte- ferent stakeholders use different levels of abstraction grate their respective architectures into the Federal to consider an enterprise and expect different deliv- Enterprise Architecture.” [FEAF] The Federal En- erables. terprise Architecture Framework is based on Zach- man framework and is shown in the figure below. 4.1.2 IFAC/IFIP Task force to develop GERAM The IFAC/IFIP Task Force on architecture for enter- prise integration has studied some existing architec- tures to propose harmonization. The result is Gener- alised Enterprise-Reference Architecture and Methodology (GERAM) (Bernus, 1997). GERAM identifies, in its most important component called GERA (Generalised Enterprise Reference Architec- ture), the basic concepts to be used in enterprise en- gineering and integration. Many have examined DODAF [Ring 2004] and the frameworks listed [Martin 2005] to determine to 5
  • 6. 4.1.3 Standardization works Intelligent Infrastructure is a layered representation Two institutional standardization bodies active to of knowledge in various forms and formats. It can develop type 2 architecture standards are: CEN cover not only the ICT layer, but also the knowledge TC310/WG1 and ISO TC184 SC5/WG1. Main out- and business layers. puts achieved are: ISO 15704 (1998) - Requirements for Enterprise Reference Architecture and Method- ologies, and ISO/EN I9439 (2003) - Enterprise Inte- 5 ARCHITECTING PRINCIPLES gration – Framework for Enterprise Modelling. However, these works are not well known in indus- Architecting principles are rules to use when elabo- try and not widely used. rating enterprise architectures. Architecting princi- ples may be generic i.e. apply to all enterprises (re- flecting some best practices), or specific (reflecting a 4.1.4 New Initiatives level of consensus among the various elements of a particular enterprise, and form the basis for making Another significant framework is TOGAF. It con- future decisions). Sometimes too many principles tains two main parts: The Architecture Development can reduce the flexibility. Many organizations prefer Method (ADM) and Foundation Architecture with to define only high level principles, and to limit the generic functions or services on which specific ar- number to between 10 and 20 (Open Group, 2002). chitectures and building blocks can be built. The Ar- chitecture Development Method is a recommended approach to building TOGAF compliant architec- 5.1 General principles tures. General enterprise architecture principles can be All the frameworks and approaches mentioned found in the literature such as for example (UNCC, 4.2 Architectures of enterprise systems 2003): (a) Business processes drive technical infra- structure, (b) Primary purpose of architecture is to There are few works done at the conceptual level facilitate rapid change, (c) EA must emphasize reus- concerning system architectures, except some partial able component building blocks, (d) Architecture approaches dealing with for example, manufacturing must be enterprise-wide, (e) EA must optimize the data (ISO 15531, MANDATE), enterprise-control enterprise system as a whole, etc. system interfaces (IEC 62264), etc. These ap- Open Group has proposed similar kind of princi- proaches are developed in a very detailed level so ples ranging from business to data, application and that they are more reference models rather than en- technical principles (Open Group, 2002). Once again terprise system architectures. More recently the these principles are at high level of abstraction. They European Technical Specification (CEN TS 14818: are no directly related to architecture features and Decisional Reference Model) was approved. It is properties. Moreover, they don’t provide examples based on the GRAI approach and shows a basic de- showing how to implement the principles. cision-making structure defined at a fairly high level Another approach can be found in the Govern- abstraction. ment of Canada’s Federated Architecture (2001) where some principles were proposed, for example: Most of bottom-up system approaches are concerned (1) Reduce integration complexity to re-engineer ap- with ICT architectures or infrastructures. For exam- plication systems to be "highly modular" and ple, ENV 13550 - Enterprise Model Execution and "loosely coupled" to be able to reuse components; Integration Services (EMEIS) is a European experi- (2) Adopt holistic approach with a (whole of enter- mental standard. It focuses on services to allow exe- prise) approach; (3) Business event-driven systems; cution of an enterprise model to control industrial (4) Plan for growth and construct for growth and processes. expansion of services (known requirements) across Other standards concerning IT architectures are: enterprise; (5) Robustness, responsive, and reliable ISO 13281.2 -Manufacturing Automation Program- with appropriate redundancy to protect against sys- ming Environment (MAPLE), Open Management tem failure, etc. Architecture (OMA) known as CORBA developed More generally speaking, when developing EA, the by Open Management Group. principle of fitness-for-purpose should be followed. The functional architecture of MAPLE focuses on It means that the architecture should be developed manufacturing application interconnection and in- only to the point at which it is fit for purpose. teroperation, it is not an enterprise-wide architecture. CORBA architecture also supports application inte- 5.2 Technical principles gration focusing on issues affecting distributed ob- ject-oriented systems. Cockburn (2003) have proposed some architecting Some research work towards intelligent infra- design principles, for example: (1) Create an inter- structure has been reported in (Lillehagen, 2002). An face around predicted points of variation (because
  • 7. things change, and we must protect the system integ- The following steps summarize some proposed rity across changes); (2) Separate subsystems by approaches towards developing active knowledge staff skill requirements; (3) Make one owner for modeling support for architectures design and opera- each deliverable (People get confused if ownership tional architecting: is unclear); (4) The program is totally program driven, with the user interface just one driving pro- 1) Provide an integrated visual knowledge gram (because user interface requirements change a modeling and execution platform lot); (5) Provide a single point of call to volatile in- 2) Develop services for active knowledge mod- ter-team interfaces (Protect developers against re- eling, supporting design and re-iteration work due to an interface change), etc. 3) Develop services for model-driven solutions Malan (2002-b) also suggested three principles to and work execution develop a ‘Minimalist Architecture’: (1) if a decision 4) Develop knowledge management services could be made at a more narrow scope, defer it to 5) Re-engineer and integrate present framework the person or team who is responsible for that scope; (2) only address architectural decisions at high- domains and views priority architecturally significant requirements; (3) 6) Mode-generate easy to use workplaces for all as decisions are added to the architecture, they stakeholders to engage in architecting, oper- should be evaluated from the point of view of their ating and managing their knowledge impact on the overall ability of the organization to adopt the architecture. The major contribution of this research and de- In TOGAF (2000) some principles underlying the velopment is the integration of a knowledge model- design and successful use of specific architectures ing techniques and services, and the introduction of were proposed, for example: (1) An architecture a common platform for use in development of enter- need only specify those services that it requires; (2) prise architectures and solutions and work execution. Elements of an architecture may specify one, more than one, or only part of a service; (3) Elements of an architecture should be defined in terms of stan- 7 RECOMMENDATIONS FOR RESEARCH dards relevant to the services they specify; (4) Ele- ments of an architecture should be reused from all Research is needed on active knowledge model- the categories of the Architecture Continuum and ing as part of an overall architecture development should support reuse of solution elements of the So- process. The following steps summarize a proposed lution Continuum; (5) Elements of the solution (or approach for introducing active knowledge modeling implementation) should be reused from all the cate- and integrated modeling and execution platforms. gories of the Solutions Continuum; (5) An architec- ture must be followed, or it is useless: formal IT 1) Understand the nature, context and benefits Governance practices are therefore recommended. of active knowledge modeling 2) Define a methodology and language for ac- tive knowledge modeling 6 ACTIVE KNOWLEDGE MODELING 3) Develop a knowledge modeling technique, An active knowledge modeling approach will in an integrating platform and services the future be part of most architecture frameworks, 4) Apply approach to the existing Architecture approaches and solutions. Framework models Existing frameworks and approaches are mostly 5) Evaluate suitability and benefits of approach describing abstracted views of the systems domains, and solution. but many initiatives will be launched in 2005 to de- velop approaches and platforms for business and These steps are being considered by partners and knowledge architectures and enterprise domains. stakeholders that have experiences and competence in both TOGAF and DODAF. Concerning enterprise systems architectures, more development of some Enterprise reference architectures at higher abstraction levels is Domains also needed. This would help re-use of some mature Wisdom Wisdom solution types to save time and cost of enterprise en- Knowledge Knowledge gineering projects. Information Information It seems interesting to develop simple architec- Data Data ture representation language that allows to better ex- Signals Signals hibit key characteristics of enterprise systems at high System abstraction level. Current enterprise modeling lan- Domains guages (IDEF for example) seem not well adapted to 7
  • 8. represent architectures features. Differentiation and Integration: Building International Consensus, Springer- clarification between enterprise architecting and en- Verlag, Berlin, pp. 175-189. terprise modeling are necessary using some concrete Chen, D., Doumeingts, G. (1996), The GRAI-GIM reference examples. The two approaches and application areas model, architecture and methodology, in: Bernus P. et al. are closely related. (Eds.) Architectures for Enterprise Integration, Chapman & Moreover differentiations between various archi- Hall, London. tectures in terms of properties and features also need CIO, (1999), Federal Enterprise Architecture Framework, Ver- to be explicitly identified so that comparison and sion 1.1, September 1999, The Chief Information Officers choice can be more easily made at a high level of Council. abstraction and early stage of design. The frame- Cockburn, A. (2002), On the Interaction of Social Issues and works and their views must become active or living Software Architecture, http://members.aol.com/acockburn, knowledge related to work throughout life-cycles. Humans and Technology (arc@acm.org). It is also necessary to continue the effort of har- ENV 13550 (1995), Enterprise Model Execution and Integra- monization. At least, a standard terminology is tion Services (EMEIS), CEN, Brussels. needed. This requires establishing collaboration be- Florijn, G. (2002), Software Architecture - Introduction & tween enterprise modeling community developing Overview, (slides), SERC, 2002. business oriented architectures, and software engi- Government of Canada (2001), www.cio-dpi.gc.ca/fap- neering people concerning the IT oriented ones. paf/documents/iteration/iterationtb_e.asp Architecture design principles were not devel- IEEE 1471-2000, Recommended Practice for Architectural De- oped to a satisfactory level that brings significant scription of Software-Intensive Systems. improvement to enterprise architecting. Further re- ISO 15704:2000(E), Industrial automation systems - Require- search is also needed in this area. Developing archi- ments for enterprise-reference architectures and method- tecting principles can be bottom-up based on best ologies. practices, and/or top-down by studying some theo- ISO/EN I9439 (2003) - Enterprise Integration – Framework for retical paradigms. Enterprise Modelling. Lillehagen, F. & Krogstie, J. 2002, Active Knowledge Models and Enterprise Knowledge Management, in Enterprise In- 8 CONCLUSIONS ter- and intra-organizational integration, Kluwer Aca- demic Publishers, Kosanke K. et al (ed.) This paper has tentatively reviewed basic concepts Lillehagen, Frank (2003a) and Helge Solheim, “The Founda- and principles of enterprise architectures. A survey tions of AKM Technology,” Concurrent Engineering Con- on some main architectural frameworks and ap- ference 2003, Madeira, July 2003. proaches is presented. To day, the architecture con- Lillehagen, Frank (2003b) and J. Kostie, S. Tinella, H.G. Sol- cept is not sufficiently exploited as a high level solu- heim, D. Karlsen, “From Enterprise Modeling to Enterprise tion structure defining solutions types. One of the Visual Scenes,” Concurrent Engineering Conference 2003. reasons is the lack of proper architecture representa- Malan, R. and Bredemeyer, D. (2002-a), Less is More with tion formalisms providing characteristic features and Minimalist Architecture, IT Professional IEEE Computer properties of enterprise knowledge dimensions and Society, September/October 2002. domains. Malan, R and Bredemeyer, D. (2002-b), Software Architecture: Central Concerns, Key Decisions, Software Architecture, ACKNOWLEDGEMENT 2002 BREDEMEYER Consulting. Martin, J. (2004), Enterprise architecture - Definition, internal This paper is partly funded by the E.C. through the communication note, 2004. Interop NoE. It does not represent the view of the Martin J. (2005). Proposal for Doctoral Dissertation, private EU nor the Interop NoE project. communications with the author. The figures are taken from papers by James Martin, Open Group (2000), TOGAF: The Open Group Architecture US Air Force. The authors are Framework, Document No. 1910, Version 6, December. The authors are responsible for the paper’s content. Open Group (2002), www.opengroup.org, Architectural Prin- ciples, 2003. Ring, J. (2003), E-Business Infrastructure Capability Assess- 9 REFERENCES ment, 2003. Tinella S. et al (2003), Model Driven Operational Solution: AMICE (1993), CIMOSA - Open System Architecture for CIM, The User Environment Portal Server, CE 2003, Madeira. 2nd edition. Springer-Verlag, Berlin. UNCC (2003), Architecture, www.uncc.edu. Bass, L., Clements, R. and Kazman, R. Software Architecture, Williams, T.J. (1991), The Purdue Enterprise Reference Archi- in Practice, Addison-Wesley, 1997. tecture, Instrument Society of America, Research Triangle Bernus, P. and Nemes, L. (1997), The Contribution of GERAM Park, North Carolina. to Consensus in the Area of Enterprise Integration, in: Ko- sanke K. and Nell J.G. (Eds.) Enterprise Engineering and

×