Enterprise Architecture Design as an Engineering Discipline
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
S. Aier et. al.: Enterprise Architecture
Available
Designonline
as anatEngineering
www.enterprise-systems.net
Discipline
AIS Transactions on Enterprise Systems 1 (2009) 1, 36-43
Enterprise Architecture
Design as an Engineering
Discipline
Stephan Aier, Stephan Kurpjuweit, Jan Saat, Robert Winter
Abstract structure, business processes, software components
and data structures as well as IT infrastructure
Enterprise architecture can provide systematic components are modeled to enable communication
support to organizational change, when and analysis of the EA [11, 22]. While there is a
requirements of respective stakeholders of business broad variety of EA literature focusing on evaluation
and IT are met. This article focuses on the design [18] and generalization [12] of EA frameworks or
of enterprise architecture and proposes a “business- discussing EA modeling [1], only few publications
to-IT” approach that considers lessons from address EA application and its benefits [14, 17]. In
classical engineering disciplines. A framework for particular an engineering approach is missing which
engineering driven enterprise architecture design is deploys EA to systematically support innovative and
presented. Since such an approach creates specific fundamental change.
requirements for tool support, an appropriate In this contribution we analyze mature engineering
software implementation is presented. disciplines to derive characteristics for a framework
Keywords: enterprise architecture, business to systematically support consistent “business-to-IT”
engineering navigator, tool support transformation. We propose the business engineering
navigator (BEN) concept to support construction,
1. Introduction navigation and analysis functionalities for artifacts
and relationships of all architectural layers – from
Organizations are subject to constant evolution. strategic aspects down to IT infrastructure. BEN
Due to the different impact, organizational change therefore provides a framework on how engineering
can be distinguished into incremental change methods can be applied to organizations. BEN
(optimization) and fundamental change. While most delivers insights on how complex design and
functional methods of business administration, such transformation challenges can be broken down to
as marketing, finance and human resources provide manageable projects. We therefore discuss how
support for optimization (e.g. six sigma) [10], the BEN can be used to systematically support to EA
structured design of innovative and fundamental design in this article.
change requires a holistic approach to systematically The next section identifies core concepts of
support organizational transformation [21]. Complex mature engineering disciplines. Following lessons
changes require a thorough understanding and learnt from classical engineering, section 3 derives
therefore a targeted documentation of the artifacts to requirements for an engineering based approach
be designed, their relationships to each other as well to EA. Section 4 introduces the BEN concept to
as a clear structuring of the transformation procedure. support a stakeholder-oriented EA management
Therefore, architectural as-is documentation, to-be (EAM) as one of multiple possible applications.
planning, and support of necessary changes are core Section 5 discusses a “business-to-IT” EAM tool
challenges for enterprise architecture (EA) analysis support and proposes ADOben as an appropriate
and design [13]. To meet these challenges, design solution. The findings are summarized, and future
objects of EA such as strategic aspects, organizational research is outlined in section 6.
36 AIS Transactions on Enterprise Systems 1 (2009) Vol. 1S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
2. Lessons from Mature or “architectural design” (short architecture) as
Engineering Disciplines central construction plan. In the following the term
“architecture” is used as synonym for the central
Mary Shaw analyzed the development of construction plan of all engineering disciplines.)
classical engineering disciplines [20]. She found All mature engineering disciplines have developed
that engineering disciplines produce cost efficient standardized construction languages for architectural
solutions for relevant problems by using scientific description. In mechanical engineering, for example,
knowledge in the artifact design process in a dozen standards exist on how to design construction
service to society. These aspects are now further plans [9]. These standards are subject to early stages
characterized: of mechanical engineering education since they are
1. “Cost efficient solutions“: Engineering does not an essential means of communication.
only imply the construction of suitable solutions,
but also emphasizes reasonable handling of 2.3. Division of Labor
given resources and conditions. Besides structuring the system to be designed,
2. “For relevant problems”: The constructed solution the construction plan is used to structure the design
addresses practically relevant problems. process: the components of a system are constructed
3. “By using scientific knowledge”: The construction in teams and then assembled in order to become a
process is comprehensible and traceable based whole according to the architecture. The division
on scientific construction languages, methods, of labor during the construction process is a core
and frameworks so that the solutions will most feature of classical engineering disciplines, since
likely fit the requirements. it is the only way to construct complex systems in
4. “In service to society”: The engineer acts in a large teams.
responsible way by providing useful innovations
to society and environment. 2.4. Architectural Design
The following subsections give an idea of Designing the architecture is the supreme
addressing these aspects by analyzing classical discipline in engineering, which involves the
engineering. transformation of requirements (problem space) into
a high level blueprint of the system to be designed
2.1. Engineering Knowledge Patterns (solution space). Designing the architecture involves
Classical engineering disciplines distinguish fundamental design decisions which have impact on
between innovative construction and construction the whole design process. An example can be found
routine. Innovative constructions have to address new in the definition of quality characteristics that the
solutions while construction routine involves reusing system to be constructed must address (e. g. Which
existing solution patterns for known problems [23]. changes to the system can be made easily, which
Construction routine is the usual design form in not? What is the system’s performance? What is
classical engineering disciplines, while innovation the capacity of the system? How scalable is the
is rather rare. To make the construction process as system?).
efficient as possible, the collection, organization, and Due to the mentioned responsibilities, great
conditioning of knowledge is necessary to make this attention is paid to architecture and only experienced
knowledge available to less experienced engineers. and highly qualified engineers are involved in
All disciplines found appropriate media for this the architectural design. By involving internal
knowledge transfer, e.g. engineering handbooks [2, and external experts as well as complex analysis
6] and tool support for collaborative engineering frameworks, engineers seek to ensure the quality
[15]. of the architectural blueprint so that the architecture
addresses all the required characteristics of the
2.2. Standardized Construction Plan and system to be designed.
Construction Language
Mature engineering disciplines use a high level 3. An Engineering Based Approach
construction plan (architecture) of the design artifact. to Enterprise Architecture
This plan depicts the main components and their
relationship to each other that is needed in order to Following the above introduced characteristics
achieve the desired behavior. (Some engineering of mature engineering disciplines, requirements
disciplines including civil engineering and software for an engineering driven approach to EA can
engineering use the “architectural blueprint” be derived. EA can be regarded as the central
I1867-7134 © GITO mbH 37S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline construction plan for organizational transformation and taking experiences from EA projects in in a “business-to-IT” approach. EA describes the companies into account, the following heuristics main business and IT components as well as can be derived. their relationships (c.f. “standardized construction plan” in classical engineering). EA is the result 3.1. Criterion of Width of important design decisions and determines EA models must address the information demand fundamental characteristics of the organization, of their stakeholders. Information demands are such as strategic positioning, business process implied by management tasks (concerns) of the efficiency and effectiveness, business/IT alignment, respective stakeholders. EA can for example deliver and information systems capabilities. Indirectly, EA crucial data for project portfolio management to therefore implies e.g. an organization’s capability support decision making, concerning investment to rapidly launch new products, to adapt to new decisions for business applications. regulations, or to exploit business potentials of IT Asuccessful method for stakeholder involvement innovations (c.f. “architectural design” in classical turned out to be the collection and analysis of engineering). precise questions that stakeholders have, e. g. Following engineering principles, concrete “Can investments in applications by justified by requirements of internal and external stakeholders additional revenue, gained from the product or build the starting point for EA design. Stakeholders service which is supported by this application?” may e.g. contribute model information and Situational fragments of the EA model (viewpoints) also consume information of the EA. As far as can help to answer such questions by representing designing stakeholders are concerned, conventions the desired information on an aggregate level and (c.f. “standardized construction language”) and in a form of representation which is appropriate governance are vital to enable distributed but for the respective stakeholder. consistent design (c.f. “division of labor” in Following the criterion of width, all artifacts classical engineering). Designing EA does not and relationships needed for the creation of imply to create new models from scratch, but to view-points must be reflected in EA. The sum of integrate and aggregate existing knowledge from information demands of all stakeholders therefore architectural parts (c.f. “engineering knowledge determines the maximum EA extent. patterns” in classical engineering). Not all of the stakeholders’ concerns and requirements 3.2. Criterion of Depth have effects on the fundamental structure of the When EA is only designed in respect to the organization (or EA), but they partially might still criterion of width, chances are high that a huge have influence as architectural drivers. number of detailed structures of implementations There exist different classes of architectural or detailed inventories of single artifacts types are drivers. One class focuses on the functional included. development of the organization. Examples can Architecture strategies which are derived be found in the opening of new markets and from the architectural drivers, and the desired sales channels or business process outsourcing. characteristics of the whole system should also be Another class of architectural drivers focuses on included in EA. These architecture strategies need optimization of organizational structures, e. g. by to be expressed and documented, so that their consolidation of redundant structures or reuse of realization is measurable. Architecture strategies existing resources to improve flexibility and prepare focus on the entire system or on groups of the organization for possible future changes. similar artifacts (This heuristic is based on the Architectural drivers tend to have tradeoffs which locality criterion, initially published by [5] and require compromises in the architectural design. then adapted by [7] This criterion is adapted for Priorities of the architectural drivers are subject enterprise architecture and informally described.) to changes which might cause discontinuities such as all core business processes, all data in organizational development. A merger, for flows across domains, or all products which are example, might change any given situation to set distributed over a certain channel. Structures the focus on architectural consolidation. which only focus on implementation details The sketched complexity of the matter often of one artifact, and which are only relevant causes difficulties for enterprise architects to for this object, should not be a part of EA. choose the appropriate artifacts and relationships Exceptions might be useful in certain situations, for the EA model. From an engineering perspective e. g. to support concerns of a key stakeholder. 38 AIS Transactions on Enterprise Systems 1 (2009) Vol. 1
S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
The relevance of an artifact can be indicated by the respective aggregated level (e. g. respective
the impact that a change of this artifact has on application and respective server cluster).
others (This heuristic is based on encapsulation Detail structures should only be included in
and information hiding, which originates in object EA when they have impact on design decisions
orientation (cf. e.g. [16]).). If a change of an with effect on the entire system. This is true
artifact does not influence others at all, it should for the deployment of application components
most likely not be included in EA. Following the on servers, since the explicit documentation
idea that EA is the blueprint for change projects, of this relationship might have considerable
problems can arise from making unnecessary impact on the ability of the organization to
design decisions for the entire architecture which react in case of a blacked out computing center.
should be better made for individual projects. An example for a relationship on detailed level
Therefore, details such as object oriented class without significant impact can be found in the
structures, detailed data structures, mapping assignment of application functions to detailed
information of network adaptors to servers, activities of a business process. In this case, the
structures of teams in individual business units, aggregate relationship between application and
workflow specifications of business processes, business process delivers sufficient information
or construction details of products should not be for EA purposes, while detail documentation
part of EA. Figure 1 illustrates our “broad and can be misleading.
aggregate” understanding of EA. 2. Objects on detailed level can be reused in
In two cases it can be useful to include detail multiple artifacts: Similar to the case above,
artifact structures in the EA model. In both cases, the detail level should only be taken into
changes to the detail structure cause potential account, if reuse has significant impact on the
changes to other artifacts, which means that the behavior of the entire system. This is the case in
above mentioned heuristic remains valid: examples such as reuse of product components
1. Relationships to other detail artifact structures: as part of a platform strategy. Contrary, it is
Examples can be found when deploying single not the case when reusing libraries in multiple
software components on servers or assigning applications.
sub-goals to the responsible business units. A Moreover, it cannot be recommended to include
relationship on detail level (e. g. application many objects of a detail structure which all have
component and server) can always be observed on similar relationships within the architecture. This
Fig. 1: Enterprise Architecture is Broad and Aggregate
Enterprise Architecture
Software and
Data
Enterprise Server and
Corporate Platforms
Services
Strategy
Detail structures
Markets
Processes
I1867-7134 © GITO mbH 39S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
Methods and Models of Business Engineering
Business Engineering Navigator
Components of Design and Analysis Knowledge
Architecture Strategies Analysis Framework
Architekturstrategien Analyseframework
Domain Specific Components
Viewpoints
Meta Model Extensions Analyseframework
Basic Components
Core Meta Modeling Analysis Query and Cons- Model
Model Mechanisms Mechanisms traint Language Management
Tool Support
Fig. 2: Architecture of the Business Engineering Navigator Approach
is e.g. the case when considering all client compu- indicator that the level of aggregation is too low.
ters (as inventory). From our experience, in most cases it is sufficient
to use and maintain more aggregate structures (as
3.3. Pragmatic Criterion proposed in the criterion of depth). Usually, high
Organizations are subject to constant changes. level models can be maintained manually with
Therefore EA models need to be updated regularly. reasonable efforts, i. e. without having to develop
Many projects show that continuous maintenance and use automated interfaces to detail repositories
efforts incur high costs. Therefore it needs to be (such as configuration management database,
considered if the benefits resulting from covering process model repository, product configuration
a stakeholder concern exceed the costs necessary system). However, there may be use cases where
to gather and maintain this information. Not every more detailed model data is needed, automated
stakeholder information demand which is claimed data imports might be necessary to provide an
by the criterion of width will gain positive revenue. efficient solution at reasonable maintenance
Therefore, the pragmatic criterion proposes to efforts.
carefully analyze and evaluate the value of artifacts
and relationships. No maintenance efforts should 4. Business Engineering Navigator
be put into artifacts which are not necessary for
any concerns [8]. BEN structures the various components of
Quantifying costs and benefits of information engineering support for EAM. BEN is based on
demand is far from trivial [e.g. 17]: Benefit the above mentioned principles of engineering
analysis often results in “reverse” considerations and addresses the main requirements of EAM.
(what if we did not have this information?). Figure 2 illustrates the components of BEN
Costs arise according to type, origin, necessary and their assignment to abstraction layers. This
conditioning efforts, and frequency of usage. structure can be used as a framework for practical
Information demands being served from the same as well as research projects. The components are
pool of data might realize considerable synergies. described in the following subsections.
The main feature of the architecture is to
provide a high level plan to support long term 4.1. Basic Components
strategic development of an organization. High Basic components include domain independent
frequency in changes of detail information incurs functionalities which are used to model, analyze and
high maintenance costs and can be used as an design EA.
40 AIS Transactions on Enterprise Systems 1 (2009) Vol. 1S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
• Core meta model: A common set of vocabulary is • Architecture strategies: Generally valid and
a major prerequisite to consistently design the five accepted design patterns and architectural
layers of the business engineering framework. The strategies (e.g. handling of redundant master
BEN meta model is based on generic modeling data) and principles can be organized as
methods and contains artifacts on a strategy layer, knowledge repositories [4].
organizational layer, integration layer, software • Analysis framework: An analysis framework
layer, and an IT infrastructure layer [22]. This implements models of quality and metrics for
meta model serves as a standardized construction the design artifacts (e.g. analysis frameworks
language for organizational transformation. which help to refine aggregate targets, such
• Modeling mechanisms: A domain independent as efficiency, into measurable counts, such
description language provides basic mechanisms as scalability, avoidance of redundancies,
to create models of the design artifacts. This capability for multi channel usage [19]). Results
includes hierarchical refinement of artifacts using of the analysis are represented as viewpoints.
“part-of” and “is-in” relationships as well as The BEN approach proposes to adapt EAM to the
domain clustering. respective application scenarios of the respective
• Analysis mechanisms: Generic types of analyses organization. Therefore, generally valid and ac-
and analysis mechanisms are instantiated for each cepted components of design and analysis know-
concrete viewpoint (cf. below). Examples for ledge must be adapted, extended and integrated.
generic types of analyses include matrix analysis, The BEN approach can be understood as
dependency diagrams, list reports, architecture interface between methods of business engineering
views, and spider web diagrams [3]. and underlying software tools: On one hand, BEN
• Query and constraint language: A query language defines requirements for software systems and
is needed to analyze the models using predefined gives assistance how to use them in the context
and ad-hoc queries. Using the constraint language, of the engineering discipline. On the other hand,
the architecture strategy and the architectural BEN is a service layer for different methods,
principles are specified and verified. Both which may give concrete guidance in change and
languages are based on formalized modeling transformation for organizations.
mechanisms, e. g. relational algebra.
• Model management: This basic component 5. Tool Support: A BEN
includes version management functionalities, such Implementation for Documen-
variants handling and model history. These aspects tation, Analysis and Design of
are crucial to model life-cycle management Enterprise Architecture and
Learnings from First Applications
4.2. Domain Specic Components
Domain specific components are instances of Regarding the criterion of width, EA addresses a
generic components for the five different layers variety of stakeholders with different information
listed in section 4.1. demands and different views on EA. Therefore the
• Meta model extensions: Specific extensions of implementation of the basic components of BEN
the core meta model allow the application of the (cf. section 4.1) requires a specific tool support
engineering approach in specific contexts (e. g. a where BEN can serve as a foundation for the
certain industry, a certain company size or maturity implementation or configuration of EA software
level) and in specific projects (e. g. business driven tools. ADOben is such an implementation of BEN
changes, IT driven changes, alignment projects). requirements based on ADONIS, a commercial
• Viewpoints: A viewpoint catalogue is comprised of modeling tool and meta-modeling platform.
generic analysis mechanisms and types of analyses ADOben implements the required model types
which are suited to given stakeholder information from a strategy layer down to an IT infrastructure
demands. Queries needed for each viewpoint can layer as well as the interdependencies between the
be formulated using the above introduced query artifacts and models on these layers. Therefore
language [11]. it is possible to design an architecture plan for
the as-is situation. Using means of architecture
4.3. Components of Design and Analysis analysis and a dedicated architecture strategy, a
Knowledge blueprint for the to-be situation can be designed.
Components of design and analysis knowledge To support the application scenarios of
help to keep record of the engineers’ knowledge. potential EA stakeholders, the tool implements
I1867-7134 © GITO mbH 41S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
01 03 04
02
Referenzprozess Referenzprozess Referenzprozess
Referenzprozess
Kundengewinnung Lieferanten- Angebots-
Reiseabwicklung
und -Beziehungs-... gewinnung und... erstellung
Referenzprozess
Referenzprozess Referenzprozess Referenzprozess Referenzprozess Referenzprozess Referenzprozess Referenzprozess
Referenzprozess Kunden- Referenzprozess Referenzprozess
Kunden- und Lieferanten- Lieferanten- Lieferanten- Kunden- Komponenten- Erstellung
Kundenwerbung Beziehungs- Reisebuchung Reisebetreuung
Marktanalyse gewinnung betreuung Anbindung bedarfsanalyse einkauf Pauschalangebote
management
Club-Urlaub  CRM-System  Finanzsystem (SAP)  CRM-System  CRM-System  Abrechnungssystem  Abrechnungssystem  CRM-System  Lieferanten-Datenbank  Lieferanten-Datenbank  CRM-System  CRM-System  Lieferanten-Schnittstellen-  Internes Mitarbeiter-
Y Finanzsystem (SAP) Schnittstelle zu Markt- Kundenverwaltungs-System Web-Portal Angebots- und Buchungssystem Angebots- und Buchungssystem Lieferanten-Schnittstellen- Lieferanten-Schnittstellen- Lieferanten-Schnittstellen- Internes Mitarbeiter- System Informationssystem
Kundenverwaltungs-System forschungsinstitut Produkt-Liste (Excel) CRM-System CRM-System System System System Informationssystem Produkt-Datenbank Produkt-Datenbank
Produkt-Liste (Excel) Web-Portal Finanzsystem Finanzsystem Web-Portal Lieferanten-Schnittstellen-
Schnittstelle zu Markt- (Individualentwicklung) (Individualentwicklung) System
forschungsinstitut Kundenverwaltungs-System Kundenverwaltungs-System Produkt-Datenbank
Web-Portal Lieferanten-Schnittstellen- Lieferanten-Schnittstellen-
System System
Produkt-Liste (Excel) Produkt-Liste (Excel)
Web-Portal Web-Portal
Einzelkomponente  CRM-System  Finanzsystem  CRM-System  CRM-System  Abrechnungssystem  Abrechnungssystem  CRM-System  Lieferanten-Datenbank  Lieferanten-Datenbank  Lieferanten-Datenbank  Lieferanten-Datenbank  CRM-System  CRM-System
Y Finanzsystem (Individualentwicklung) Kundenverwaltungs-System Web-Portal Angebots- und Buchungssystem Angebots- und Buchungssystem Lieferanten-Schnittstellen- Lieferanten-Schnittstellen- Lieferanten-Schnittstellen-
(Individualentwicklung) Produkt-Datenbank CRM-System CRM-System System System System
Kundenverwaltungs-System Web-Portal Finanzsystem Finanzsystem Web-Portal
Produkt-Datenbank (Individualentwicklung) (Individualentwicklung)
Web-Portal Kundenverwaltungs-System Kundenverwaltungs-System
Lieferanten-Schnittstellen- Lieferanten-Schnittstellen-
System System
Produkt-Datenbank Produkt-Datenbank
Web-Portal Web-Portal
Fig. 3: Three Dimensional Matrix Report in ADOben
the respective queries and visualizes their ADOben, especially matrix analyses have turned
results. The following example illustrates an out to be a valuable tool to foster and rationalize
application scenario in which a business analyst the communication between the IT unit and
plans the launch of a new product. Information the business units as well as to systematically
demands of the business analyst could be: “Do address alignment questions between business
we have adequate application support for the new structures and IT structures.
product?”, “Where are potential breaks between
applications along the process?” Using the query 6. Conclusion
“Which applications are used in which process
for which product?” on the architecture model, Based on analysis of classical engineering
a matrix report in three dimensions as shown disciplines, this paper presents an engineering
in Figure 3 is created. The matrix shows the approach to EAM which has been generalized
products and processes as well as the underlying as BEN. It is shown how EA models can be
applications. constructed based on stakeholder requirements in
Based on a generic core meta model and order to create a pragmatic solution representing
generic analysis mechanisms as well as specific a “broad and aggregate”, business-to-IT
extensions for a defined application scenario, architecture – and not a set of enterprise-wide
every other query could be run on the underlying detail models which will never be completed
models and visualized in a report. and soon be outdated. BEN delivers a foundation
Since BEN is not particularly developed for for efficient EA design and EAM. BEN can
EAM, the generic concepts (as presented in be implemented in software tools and applied
section 4) could also be implemented in different using business engineering methods to enable
tools and for other business engineering methods. structured solution design.
As a first means of feasibility evaluation the BEN Engineering disciplines in general, BEN and
approach has been implemented in a German ADOben show that the engineering of complex
financial service provider using ADOben. The environments involves a complex ‘mechanism’.
application of the approach verified that EA This mechanism can be evaluated according to
should be positioned as a planning tool, not as a its applicability and to its connectivity to other
tool focused on operative tasks (like for example approaches, tools, and methods. The development
a configurations management database system of this mechanism is aimed at a clear structure so
triggering an alarm when a server hard disk fails). that elements can be arranged according to the
To achieve this, the three criteria defining EA respective situation as a best-of-breed solution.
scope have proven to be valuable. The criterion This means that ADOben is one solution to
of width requires that the EA meta model and the implement BEN as an EAM tool. At the same
viewpoints are developed in close collaboration time BEN is not limited for the use in the context
with all stakeholders of the EA. To get the of EAM. The core idea is to ensure structured
buy-in of the stakeholders, the introduction of engineering. Further research activities in this
EAM should be taken as a chance to revise the area will focus on the methods themselves and
planning and documentation processes within their situational character. The ultimate goal is
the organization in order to ensure that the EAM to provide engineering support for the situational
organization concept is integrated seamlessly development and maintenance of “business-to-
and does not cause an overhead work load for IT” solutions – in the context of EAM, but also
the stakeholders. The analysis capabilities of for integration management, for information
42 AIS Transactions on Enterprise Systems 1 (2009) Vol. 1S. Aier et. al.: Enterprise Architecture Design as an Engineering Discipline
logistics management, for IT/business alignment Technology for Knowledge-based Collaborative
Engineering, Concurrent Engineering, 1(3), 137-146.
and other scenarios in information management. [16] Parnas, D.L.: (1972). On the criteria to be used in
decomposing systems into modules, Communications
References of the ACM, 15(12), 1053-1058.
[17] Schekkerman, J.: (2005). The Economic Benefits of
[1] Arbab, F., de Boer, F., Bonsangue, M., Lankhorst, M., Enterprise Architecture: How to Quantify and Manage
Proper, E., & van der Torre, L.: (2007). Integrating the Economic Value of Enterprise Architecture.
Architectural Models. Symbolic, Semantic and Victoria, British Columbia: Trafford Publishing.
Subjective Models in Enterprise Architecture, [18] Schekkerman, J.: (2004). How to Survive in the Jungle
Enterprise Modelling And Information System of Enterprise Architecture Frameworks: Creating or
Architectures, 2(1), 40-56. Choosing an Enterprise Architecture Framework.
[2] Avallone, E.A., Baumeister, T., & Sadegh, A.: (2007). Victoria, British Columbia: Trafford Publishing.
Marks’ Standard Handbook For Mechanical Engineers. [19] Schelp, J., & Stutz, M.: (2007). A Balanced Scorecard
Mcgraw-Hill Professional. Approach to Measure the Value of Enterprise Architecture,
[3] Bucher, T., Fischer, R., Kurpjuweit, S., & Winter, Journal of Enterprise Architecture, 3(4), 8-14.
R.: (2006). Analysis and Application Scenarios of [20] Shaw, M.: (1990). Prospects for an Engineering
Enterprise Architecture - An Exploratory Study, Discipline of Software, IEEE Software, 7(6), 15-24.
EDOC Workshop on Trends in Enterprise Architecture [21] Winter, R.: (2008). Business Engineering -
Research (TEAR 2006), Tenth IEEE International Betriebswirtschaftliche Konstruktionslehre und ihre
EDOC Conference (EDOC 2006). Hong Kong: IEEE Anwendung in der Informationslogistik. In Dinter, B.,
Computer Society. Winter, R. (Eds.), Integrierte Informationslogistik. (pp.
[4] Buckl, S., Ernst, A.M., Lankes, J., & Matthes, F.: (2008). 17-38). Berlin, Heidelberg: Springer.
Enterprise Architecture Management Pattern Catalog. [22] Winter, R., & Fischer, R.: (2007). Essential Layers,
[5] DeRemer, F., & Kron, H.H.: (1976). Programming- Artifacts, and Dependencies of Enterprise Architecture,
in-the-large versus programming-in-the-small, IEEE Journal of Enterprise Architecture, 3(2), 7-18.
Transactions on Software Engineering, 2(2), 80-86. [23] Zwicky, F.: (1948). Morphological Astronomy, The
[6] Dubbel, H., Kuttner, K.H., & Beitz, W.: (1994). Dubbel. Observatory, 68(845), 121-143.
Handbook of Mechanical Engineering. Berlin: Springer.
[7] Eden, A.H., & Kazman, R.: (2003). Architecture,
Design, Implementation, International Conference on Stephan Aier
Software Engineering (ICSE). Portland, OR: Institute of Information Management,
[8] Fischer, R., Aier, S., & Winter, R.: (2007). A University of St. Gallen,
Federated Approach to Enterprise Architecture Model
St. Gallen, Switzerland,
Maintenance, Enterprise Modelling and Information
Systems Architectures, 2(2), 14-22.
E-Mail: stephan.aier@unisg.ch,
[9] Giesecke, F.E., Mitchell, A., Spencer, H.C., Hill, I.L., Phone: +41 71 224 3360
Dygdon, J.T., Novak, J.E., & Lockhart, S.D.: (2008).
Technical Drawing. Denver, CO: Pearson Education. Stephan Kurpjuweit
[10] Harry, M.J.: (1988). The Nature of Six Sigma Quality. Institute of Information Management,
Rolling Meadows, IL: Motorola University Press. University of St. Gallen,
[11] IEEE: (2000). IEEE Recommended Practice for St. Gallen, Switzerland,
Architectural Description of Software Intensive E-Mail: stephan.kurpjuweit@unisg.ch,
Systems (IEEE Std 14712000). New York: IEEE
Phone: +41 71 224 3316
Computer Society.
[12] IFIP-IFAC Task Force on Architectures for Enterprise
Integration: (2003). GERAM - The Generalised Enterprise Jan Saat
Reference Architecture and Methodology. In Bernus, P., Institute of Information Management,
Nemes, L., Schmidt, G. (Eds.), Handbook on Enterprise University of St. Gallen,
Architecture. (pp. 22-62). Berlin et al.: Springer. St. Gallen, Switzerland,
[13] Johnson, P., & Ekstedt, M.: (2007). Enterprise E-Mail: jan.saat@unisg.ch,
Architecture - Models and Analyses for Information Phone: +41 71 224 3782
Systems Decision Making. Pozkal: Studentlitteratur.
[14] Kurpjuweit, S., & Winter, R.: (2007). Viewpoint-based
Robert Winter
Meta Model Engineering, Enterprise Modelling and
Information Systems Architectures - Concepts and
Institute of Information Management,
Applications, Proceedings of the 2nd Int’l Workshop University of St. Gallen,
EMISA 2007. Bonn: Gesellschaft für Informatik, Köllen. St. Gallen, Switzerland,
[15] McGuire, J.G., Kuokka, D.R., Weber, J.C., Tenenbaum, E-Mail: robert.winter@unisg.ch,
J.M., Gruber, T.R., & Olsen, G.R.: (1993). SHADE: Phone: +41 71 224 2190
I1867-7134 © GITO mbH 43You can also read
