Engineering the Sustainable Business: An Enterprise Architecture

advertisement
ENGINEERING THE SUSTAINABLE BUSINESS:
AN ENTERPRISE ARCHITECTURE APPROACH
OVIDIU NORAN
N44 1.23 Nathan Campus Griffith University
Brisbane QLD 4111
Phone: +61-7-3735-5382
Fax:
+61-7-3425-3704
E-Mail: O.Noran@griffith.edu.au
ENGINEERING THE SUSTAINABLE BUSINESS:
AN ENTERPRISE ARCHITECTURE APPROACH
Short Biography:
Ovidiu Noran holds a PhD in Enterprise Architecture, a Masters in Information and Communication
Technology and an Engineering degree in Building Services and Automation. He has worked as an
engineer and business architecture/management consultant for companies in Europe and Australia and is
currently lecturing Enterprise Architecture and Systems Engineering at Griffith University. He is a
member of several professional bodies (Engineers Australia, Australian Institute of Management, etc) and
standardization committees ISO/IEC/SC7/WG42 and ISO/TC184/SC5/WG1. His seminars, publications
and regular involvement in conferences and journals highlight research interests in Artificial Intelligence,
Software Engineering and Enterprise Architecture and a preference for Action Research.
Manuscript Exceeding 5000 words. Reasons:
1) the chapter presents the use of two highly complex concepts : an Enterprise Architecture Framework
and a Meta-methodology that required proper introduction. In addition, explanation of other essential
environmental-specific concepts (necessary in an EA-oriented book) make up to around 850 words.
2) the proposed chapter is thoroughly referenced. The references alone constitute almost 1000 words.
The manuscript has not been presented at any conference. However the EA concepts presented have been
validated in several published case studies (referenced in the proposed chapter).
ENGINEERING THE SUSTAINABLE BUSINESS:
AN ENTERPRISE ARCHITECTURE APPROACH
Abstract:
Sustainability has always been an essential issue for the profitable business. Nowadays however,
environmental responsibility is fast becoming just as important as economic viability as climate change
theories turn into a grim reality and relevant regulations are expected to tighten significantly in the near
future. Businesses typically react to this challenge by implementing environmental reporting and
management systems; however; often the company does not reap the full benefits from such initiatives,
mostly because the environmental approach is not integrated in the overall strategy and management is
not supported by appropriately aggregated and available environmental information. This chapter argues
for the necessity and benefit of integrating the proposed environmental management (EM) project into the
ongoing ‘extended’ enterprise architecture (EA) initiative present in all successful companies. This is
done by demonstrating how a reference architecture framework and a meta-methodology using EA
artefacts can be used to co-design the EM system, the organisation and its information system in order to
achieve a much needed synergy between the business and environmental strategic management.
Keywords: Enterprise Architecture, Enterprise Engineering, Sustainability, Sustainable Development,
Environmental Management System, Meta-methodology, GERAM, ISO15704, ISO 14001
Engineering the Sustainable Business: an EA Approach
Author
ENGINEERING THE SUSTAINABLE BUSINESS: AN ENTERPRISE
ARCHITECTURE APPROACH
ENVIRONMENTAL SUSTAINABILITY – THE OTHER ISSUE OF THE NEW CENTURY
One of the main concerns of businesses of all times has been their capacity to survive and adapt to
changes in the commercial environment and thus to remain productive for their entire envisaged life span
– hence, to be an economic sustainable business. History has shown however, that the continued existence
of businesses also strongly depends on their impact on the natural environment and the way they treat
their workers. This basic truth was emphasized by Elkington’s (1998) Triple Bottom Line (TBL)
approach to business sustainability: one must achieve not only economic bottom-line performance but
environmental and social performance as well. Blackburn (2007) compares economic sustainability to air
and environmental and social sustainability to food: the first is more urgent but not more important than
the second. Blackburn also rightfully asserts that ‘the 2Rs’ – Respect for humans (and all life) and
judicious management of Resources – form an essential component of overall sustainability of the
business (in this chapter also called ‘enterprise’, ‘company’ or ‘organisation’).
Hence, a successful enterprise must take a whole-system, integrated approach towards sustainability,
understood in this chapter as an abbreviation for the Brundthal Report notion of sustainable development
that “…meets the needs of the present without compromising the ability of future generations to meet
their own needs.” (UN World Commission on Environment and Development, 1987).
Tackling Environmental Sustainability Challenges
The current mainstream consensus is that climate change is real and happening at a rate faster than
initially thought. In these conditions it is to be expected that environmental legislation will become
considerably more restrictive, customer and stakeholder expectations will be much higher and
environmental damage clean-up and prevention expenses will increase substantially. On the opportunity
side however, sustainability will become an even more effective device to manage intangible but essential
assets such as corporate image, brand and reputation (Aust. Dept. of Environment and Heritage, 2003).
Presently, it appears that the main challenges brought by sustainability are integration and coherence.
Thus, environmental responsibility must permeate all aspects and levels of the business and the
environmental constraints must be consistently understood and managed across the organisation, in an
integrated manner, in order to preserve the coherence of the business units.
Meeting these challenges requires setting up an environmental management (EM) project with:
a) top-management support for the project champion(s) (CEO can be one, however not the only one);
b) sufficient authority and appropriate human / infrastructure resources allocated;
1
Engineering the Sustainable Business: an EA Approach
Author
c) a suitable environmental strategy, integrated in the general company strategic direction;
d) a cross-departmental approach, horizontally and vertically;
These prerequisites are essential if the project is to trigger organisational culture change (to determine
permanent changes in the way people do things) and to include changes in the enterprise’s information
system (IS) for effective access to environmental information facilitating the decision-making process
(Molloy, 2007; Nilsson, 2001).
The above-mentioned issues match to a good extent the scope of a typical ‘extended’ (i.e. applying to
the entire organisation, not only to its IS / IT subsystem (Doucet et al., 2008)) enterprise architecture (EA)
project. This match may provide a solution to an integrated, coherent approach to the introduction of
environmental issues in the management and operation of all business units. This is desirable because a
company whose architecture includes environmental management, competencies and responsibilities in
an integrated fashion will have the necessary agility and preparedness not only to cope with, but even
thrive on the challenges brought about by climate change and global warming, thus turning a potential
weakness into a strength. Hence, changes in the economic, natural and/or social environment will produce
less knee-jerk, interventionist management behaviour and organisational turbulence, since the capacity to
cope with change will be built-in rather than imposed. The company will be able to adapt promptly and
naturally, according to well-defined and effective policies including environmental adaptability.
Environmental Sustainability and Enterprise Architecture
The quest to evolve a business towards environmental sustainability occurs in a complex environment:
there are risks, legal and financial constraints, government agencies, non-governmental organisations
(NGOs), public opinion, stakeholders and corporate social responsibility (CSR) considerations. On the
other hand, there is also a growing body of specialised literature, current and emerging standards,
reporting frameworks and consultant companies, all offering to help and guide towards business
sustainability assessment, design, implementation and reporting / monitoring in various degrees of detail.
This has the potential to assist but at the same time compound what already constitutes a complex
enterprise engineering (EE) task.
The project to create or evolve the environmentally sustainable business involves several typical steps,
such as: identifying the business processes and understanding their impact on the environment (the ASIS), defining a vision and concept(s) for the future state (the TO-BE), eliciting and specifying
requirements to reach the selected TO-BE state, (re)designing the processes, policies and often the entire
organisation according to these requirements, implementing them, continually monitoring the effects and
applying some of the previous steps for correction and enhancement. These phases reflect the continuous
improvement Plan-Do-Check-Act cycle (Shewhart, 1986) which is underlying the majority of the
2
Engineering the Sustainable Business: an EA Approach
Author
mainstream environmental sustainability support artefacts available nowadays.
As in any project start-up, the stakeholders and project manager are faced with several immediate
problems. What is the state of the business now (AS-IS), and how sustainable (TBL-wise) is it? What are
the requirements and the baseline? What is that the business wants to achieve (TO-BE state): minimum
compliance with the law in the short term, or forward-looking policies and processes, with the afferent
risks and unknown productivity effects in the short term? How are they going to get to the desired TO-BE
state, namely what do they actually do next? And if help is available, which artefacts can be used, when
and where? Should they require outside help (e.g. sustainability consultants) - and then what to ask for?
This chapter argues for the necessity and benefit of integrating the proposed EM project into the
ongoing extended EA initiative present in all successful companies (note that in this chapter, EA is
understood as extended EA unless otherwise stated). For example, strategic integration of EM is only
achievable if necessary information is quickly available and is of high quality (Molloy, 2007). Thus,
information must be at the fingertips of managers in the form and level of aggregation they need as agility
is not compatible with delays due to digging out and filtering suitable information separately for each
request. Moreover, companies need the environmental aspect to be present on all levels of management,
which effectively calls for an environmental decision support system. For such reasons, the ongoing EA
project needs to be fully aware of the environmental sustainability project so that all information / process
/ organisational / technical aspects are taken care of in an integrated manner.
CURRENT PROBLEMS AND SOME PROPOSED SOLUTIONS
While initially environmental activities were mostly triggered by legal action and involved addressing the
effect (compensation, treatment, etc) rather than the cause, climate change, changing regulations and
growing public awareness and pressure have resulted in the environmental aspect being considered in all
life cycle phases of the company and its products. In addition, the intended environmental scope has
gradually extended from the operational level (reflex reactions to regulations and law suits) to tactical and
strategic level. However, to date most of these efforts are still disjointed, i.e. specific to business units and
not properly supported by the ICT infrastructure. This means that a) the company loses coherence as
different units approach environmental sustainability in different levels of detail and at a different pace
and b) top management cannot effectively use the information generated by the environmental reporting
functions due to language, format, level of aggregation etc.
The Environmental Management System: A Silver Bullet?
Companies typically address the mandated and / or perceived requirement to introduce environmental
responsibility in their business units by attempting to implement some type of environmental reporting
3
Engineering the Sustainable Business: an EA Approach
Author
and environmental management system (EMS). An EMS is intended to be part of an organization's
management system that is used to develop and implement its environmental policy and manage its
environmental aspects (ISO, 2004). Thus, it is typically seen as an add-on to the existing management that
also enables the organisation to benchmark its environmental performance and evaluate its performance
and improvement (note that in this chapter, environmental measurement and reporting are seen as
functions of the EMS acting as a decision support system).
While an EMS is a significant step in the right direction, when implemented in isolation it will not
trigger the cultural change necessary to make environmental responsibility ‘stick’ in the company. Some
authors (Coglianese and Nash, 2001) argue that the implementation of an EMS alone (especially if
imposed on the organisation for various reasons), is irrelevant if the company does not have a real
commitment to environmental improvements as a prerequisite. For example, ISO 14001:2004 only
requires that EMS-s be designed in such a way that companies can work toward the goal of regulatory
compliance and seek to make improvements, not that the company actually achieves environmental
excellence or even full compliance with existing laws! Hence, it appears that to be effective, EMS-s must
be backed by regulation and enforcement by e.g. environmental protection agencies (EPAs).
Various reference models (frameworks, methods etc) for EMS design have emerged. However, each
company is different and therefore EMS implementations using such reference models require their
customisation - which needs knowledge of those artefacts and may result in ‘locking’ the company in a
particular proprietary solution.
Methods, Frameworks, Standards … and other Artefacts
Generally, the available definitions of sustainability do not provide enough detail to translate into action
effectively. (Blackburn, 2007) addresses this problem by proposing a ‘Sustainability Operating System’
(rather than an EMS) which is in fact a management method to achieve sustainability based on the
Brundthal report, the ‘2R’s and the TBL approach applied to sustainability. Willard (2002) also
recommends a TBL-based approach encompassing economy / profit, environment / planet and equity /
people with seven benefits: easier hiring and retention, increased productivity, reduced manufacturing /
commercial sites expenses, increased revenue / market share and reduced risk. Clayton and Redcliffe
(1998) propose a systems approach to integration of sustainability aspects into the business and define the
concept of environmental quality as capital (and thus the feasibility of ‘tradable pollution’).
EM frameworks aim to provide a structured set of artefacts (methods, aspects, reference models, etc)
specialised for the EM area. Some examples are The Natural Step (TNS) Framework, using a systemsbased approach to organisational planning for sustainability (Upham, 2000), The Natural Edge Project
(TNEP, 2007) which proposes a holistic approach (‘Whole System’) taking into account system life cycle
4
Engineering the Sustainable Business: an EA Approach
Author
and Life Cycle Management, a framework of concepts, techniques and procedures aiming to achieve
continuous environmental improvement from a life cycle perspective. (Hunkeler et al., 2001).
Assessment and reporting frameworks aim to assist the measurement and reporting functions of the
EMS. For example, the Life Cycle Assessment (LCA) method measures the environmental impacts of
products or services relative to each other during their life cycles (EPA, 2008). The Global Reporting
Initiative’s Sustainability Reporting Framework (GRI, 2002) contains reporting principles, guidance and
standard disclosures that are claimed to be applicable to all types of businesses.
International Standards also cover the EM issue. ISO 14000 is a set of reference models for setting up
EMS-s, life-cycle assessment, environmental auditing of processes, environmental labelling and
environmental performance evaluation. ISO 14001:2004 deals specifically with EMS-s, aiming to provide
a framework for a holistic and strategic approach to the organization's environmental policy, plans and
actions (ISO, 2004). Standards provide a good starting and reference point for design and assessment;
however, current EM standards do not define EM performance levels that the company should meet.
As can be seen, many frameworks, methods, etc recognize the need to analyse the life cycle of the
products. However, often there is a need to take into account the life cycle of the host company, the
project set up to create the EMS and especially of the EMS itself and analyse the interactions between
these entities in the context of their life cycles. This approach provides a holistic approach allowing to
represent and clarify business, EM project, EMS and product AS-IS and TO-BE states and identify
potential problems and aspects that may not be otherwise obvious. Suitable frameworks describing
systems during their entire life (not just at particular points in time), or life cycle architectures are
commonly used in EA. Therefore, in this chapter we argue that EA artefacts can systematize and provide
guidance and coherence in implementing an EMS, while at the same time creating a synergy between EM
and EA and providing am integrated solution for environmental, social and economic sustainability.
ENTERPRISE ARCHITECTURE FRAMEWORKS, GERAM AND GERA
Enterprises are highly complex systems. Therefore, sets of models (sometimes aggregated in architectural
descriptions corresponding to viewpoints (ISO/IEC, 2007)) are produced using various languages in order
to control this complexity and allow the enterprise architect and other stakeholders to focus on various
aspects of the business. As models themselves can get complex, modelling frameworks (MFs) are often
used to structure them according to various criteria. In addition, several other types of artefacts are
commonly used in EA practice, such as methods, reference models (synonymous with ‘partial models’ in
this chapter), ontologies, meta-models, glossaries, etc. All these are typically organised in architecture
frameworks (AFs), some of which have underlying metamodels formally describing their structure.
Currently there are several mainstream AFs, generic (e.g. PERA (Williams, 1994), or TOGAF (The Open
5
Engineering the Sustainable Business: an EA Approach
Author
Group, 2006)) or aimed at various domains such as manufacturing (CIMOSA (CIMOSA Association,
1996), ARIS (Scheer, 1999), GRAI (Doumeingts, 1984)), defence (DoDAF (DoD Architecture
Framework Working Group, 2003)) and information systems (Zachman (Zachman, 1987)) to name a few.
GERA
EEM
Generalised Enterprise
Reference Architecture
Identifies concepts of
Enterprise Integration
1..*
EML
1..* Enterprise Engineering 0..* 1..*
Methodology
employs
Describes process of
enterprise engineering
utilises
0…*
Enterprise Modelling Language
Provides modelling constructs for
processes, technologies and human role
implemented in
GEMC
0..*
0..*
Generic Enterprise
Modelling Concept
1..*
implemented in
supports
0..*
Defines the meaning of
enterprise modelling constructs
0..*
EET
Enterprise Engineering
Tool
Supports Enterprise
Engineering
used to build
PEM
0..*
supports
EM
Partial Enterprise Model
Provides reusable reference
models and designs of
processes, technologies and
human roles
0..*
1..*
Enterprise Model
is a kind of
Supports Enterprise Engineering
1..* used to
implement
1..*
EMO
EOS
Enterprise Module
Enterprise Operational
System
Provides implementable modules of operational
processes, technologies and human professions
0..*
1..*
used to implement
Supports the operation of the
particular Enterprise
Figure 1. A possible high-level meta-model of GERAM (based on (ISO, 2000))
In this chapter we have selected a reference AF obtained by generalising other AFs and thus considered to
be expressive enough to contain all the elements necessary for the EE task at hand, namely achieving
environmental sustainability using EA artefacts. This AF is GERAM (Generalised Reference Architecture
Framework and Methodology), described in Annex C of ISO 15704:2000. Despite its name (owing to
historical reasons), GERAM contains several other elements in addition to its reference architecture
(GERA) and methodologies (EEMs, see Figure 1). Among others, GERAM has been used in practice to
guide EE projects (Bernus et al., 2002; Mo, 2007; Noran, 2004c) and in theory to assess other enterprise
AFs (Noran, 2003, 2004a, 2005a; Saha, 2007) and to build a structured repository of AF elements for a
proposed decision support system (Noran, 2007a). GERAM is fully described in (ISO, 2000).
The main component of the Reference Architecture of GERAM, called GERA (see Figure 2), is an MF
containing an extensive set of aspects including management, life cycle, organisational, human (with
extent of automation) and decisional – all of which are considered instrumental for the following analysis.
6
Engineering the Sustainable Business: an EA Approach
Author
Generic
Partial
Particular
Views
Instantiation
Management
and Control
Identification
Concept
Product or Service
Requirements
Software
Hardware
Prelim. design
Design
Resource
Organisation
Information
Function
Detailed design
Implementation
Operation
Decommission
Machine
Human
LC phases
Figure 2. The GERA Modelling Framework (ISO, 2000)
AN ENTERPRISE ARCHITECTURE APPROACH TOWARDS ENVIRONMENTAL
MANAGEMENT PROJECTS
A Meta-methodology for Enterprise Engineering Projects
To illustrate the EA approach towards setting up and operating the EMS and the EM project we propose
to use the set of steps described in (Noran, 2005b, 2007b) that are structured in a meta-methodology, i.e.
a method to build methods applicable for specific types of EE tasks. The proposed meta-methodology
comprises three major steps and a set of sub-steps. In the first step, the user is prompted to create a list
containing entities of interest to the project in question, making sure to include project participants, target
entities (organisations, other projects) and importantly, the EE project itself. The second step comprises
the creation of business models showing the relations between the previously listed entities in the context
of their lifecycles, i.e. illustrating how entities influence each other within each life cycle phase. The third
step assists the user in inferring the set of project activities by reading and interpreting the previously
represented relations for each life cycle phase of the target entities. The resulting activities must be
detailed to a level deemed as comprehensible (and thus usable) by the intended audience.
The first meta-methodology sub-step calls for the selection of suitable aspects (or views) to be modelled
in each stage; the life cycle aspect must be present since it is essential to the meta-methodology. The
selection of a MF is also recommended, as MFs typically feature structured collections of views that can
7
Engineering the Sustainable Business: an EA Approach
Author
be used as checklists of candidate aspects and their intended coverage. This sub-step also calls for the
identification and resolution of any aspect dependencies. The second sub-step asks the user to determine
if the present (AS-IS) state of the views previously adopted needs to be shown and whether the AS-IS and
future (TO-BE) states should be represented in separate or combined models. Typically, the AS-IS state
needs to be modelled when it is not properly understood by the stakeholders and / or the TO-BE state is to
be evolved from the AS-IS (i.e. no radical re-engineering is likely to occur). The third sub-step requires
the selection of suitable modelling formalisms and modelling tools for the chosen aspects, according to
the target audience of the models and to competencies and tools available in the organisation.
Project Scope
Best Practice
Environment
Factors
Reassess
Context
knowledge
Build
Entity
List
Build
Business
Model
Build
Activity
Model
(tacit,
reasoning,
explicit,..)
New
Knowledge
(expressed
in Models)
Substeps
Aspects
(Views)
Language,
Tools
AS-IS,
TO-BE
Legend:
(NIST, 1993)
Architecture
Framework
Elements
Enterprise
Architect,
CxO, Tools
control
output
input
Activity
resource
Figure 3. Simplified meta-methodology concept (Noran, 2007a)
Note that all the above-described steps and sub-steps have underlying logic usable to automate the metamethodology (Noran, 2007a) and to guide the user in the decision-making process. This task is also
assisted by additional models and artefacts built and adopted during the second stage. A full description
of the meta-methodology is beyond the scope of this chapter and can be found in (Noran, 2004b, 2008).
In this particular case, the main meta-methodology deliverable would be a model of a method to set up
the EM project and the EMS taking into consideration the internal and external business life cycle
context. Since the management of the organisation and all other entities (business units, other
organisations, agencies, laws etc) that need to be involved in the EM project and the EMS are to be
included in the entity list (first step in Figure 3, left), their influence will be taken into account throughout
8
Engineering the Sustainable Business: an EA Approach
Author
the life cycle of the EM project and the EMS. An important initial premise for EM integration into the
organisation is thus fulfilled. As can be seen from Figure 3, the meta-methodology assists in creating new
knowledge – in this case, how to go about setting up and operating the EM project and the EMS – based
on context knowledge – i.e. know-how of running the business including its corporate culture (‘how
things are done around here’), relations with suppliers, clients, authorities etc, typically available at
middle and top management level and within CxO and enterprise architect roles. The involvement of
these roles in the methodology creation process establishes the conditions for management buy-in and
support for the upcoming EM project and early involvement of the EA department in the EM project. This
will create the best conditions for integrated development of the EMS and supporting functions of the IS.
First Step: Creating the Entity List
Often, selecting views or an MF (as required by the first sub-step) is unnecessary in this early stage, as
too many details can in fact be counter-productive. The AS-IS and TO-BE states (sub-step two) can be
represented in a combined manner as the low complexity of the models does not justify the overhead of
consistency checking. The modelling formalism chosen in sub-step three can be simply text at this stage.
As a result, an entity list can built in the first meta-methodology step using text to represent a combined
AS-IS and TO-BE state. Proposed members in the entity list are the company as a whole, business units,
the EM project, the EMS, environmental reports, NGOs, the government, EPA, EM Principles (e.g. 2R,
TBL), EM laws, EM standards, EM frameworks, assessment and reporting frameworks, social
responsibility standards, Quality Standards and EM consultants.
Second Step: Building the Business Model
This step requires the creation of a business model showing interactions of the entities previously elicited
in the context of their life cycle phases. In sub-step one the life cycle, management, decisional and
organisational aspects are selected to be modelled for the entities participating in the project. This choice
is obvious due to the nature of the system being designed (management) and also due to the importance
attached to the decisional and organisational aspects as essential factors in the integration of the EMS and
the intent to trigger cultural change. The GERA MF (see Figure 2) is adopted as the most likely to
provide a suitable formalism for the mandatory life cycle dimension and for the other selected aspects.
In this case, the TO-BE state is incremental and based on the AS-IS rather representing radical change.
Therefore in sub-step two, it can be decided that the AS-IS state needs to be represented for all aspects.
While there is no tangible advantage in showing separate AS-IS and TO-BE states in the business model,
it is very useful to do so in the decisional / organisational structure. This is because as previously shown,
in this particular EE task it is imperative to show where and how the functions of the EMS interact with
9
Engineering the Sustainable Business: an EA Approach
Author
the existing system so as to ascertain the degree of integration and effects of the EMS on the decisional
and organisational structure of the host company. Separate AS-IS / TO-BE decisional / organisational
models may also help define several TO-BE (‘what-if’) scenarios.
A modelling formalism based on the GERA MF is chosen for the business model in sub-step three (see
Figure 4). GRAI–Grid (Doumeingts et al., 1998) is selected to represent decisional and organisational
aspects, together with a plain graphical editor as a modelling tool. GRAI-Grid is optimal in this case due
to its ability to represent both the decisional and organisational aspects on the same diagram (minimal
number of languages and formalism reuse in building the models, as best-practice, is one of the rules
attached to the selection criteria within the automated version of the meta-methodology).
Formalism used
in the Business Model
Partial level of
GERA Modelling
Framework
P
Identification
Management
and Control
Concept
Cust Service
Requirements
Prelim. design
Software
Hardware
Implementation
C
R
PD
Resource
Organisation
Information
Function
DD
I
Op
Operation
Decommission
Id
Simplify
Design
Detailed design
M
Machine
Human
D
Figure 4. Formalism used for the business model
As previously shown, the business model is constructed based on context knowledge (often tacit and
requiring eliciting (Kalpic and Bernus, 2006)) owned by stakeholders, i.e. CxO, enterprise architect, top
management, etc. Any partial models that can help in this effort are considered for use, e.g. high-level
guidelines contained in the EMS standards, EM assessment and reporting frameworks, etc. Note that
before use, all such artefacts should be first assessed using the GERAM reference AF to determine their
actual scope and usefulness. A Structured Repository containing AF elements organised based on the
results of such assessments exists and is being further developed (see (Noran, 2008) for details).
A possible outcome of this second step is shown in Figure 5. As can be seen, the relations between the
relevant entities can be explicitly represented for each life cycle phase. Note that some entities’ life cycle
representation has been reduced to the phase(s) relevant for the EM project. For example, we are only
10
Engineering the Sustainable Business: an EA Approach
Author
interested in the Operation life cycle phase of Auditors, EM Standards and EM assessment / reporting
frameworks since they are not being designed / built as part of the EM project. The figure also shows the
relations between the company, the EM project and the EMS, which allows to build consensus, achieve a
common understanding and explicitly represent what needs to be done, phase by phase, at a high level. A
few examples: the EMS is built by the EM project; however, EM consultants may also be involved in the
design. The company is lobbied by NGOs and has to abide by EM Laws. Auditors perform either
certification audits (affecting the concept and design of the EMS) or surveillance audits (to check if the
EMS is still compliant). The EPA will look into the EMS operation and receive information from external
auditors. Importantly, the EMS should be able to redesign itself (arrow from Mgmt operation to the other
life cycles) to a certain extent and thus be agile in the face of moderate EM regulation and market
changes. Reaction to major changes should be however delegated to the upper company management.
P
M
Id
C
R
EML
PD
DD
I
Op
D
Comp
EMP
NGO
CL
Gvt
EMSt
SP
AU
EMC
BU AF
RF
EPA
EMS
Id: Identification; C=concept; R=requirements, PD=preliminary Design
DD=Detailed Design, I=Implementation, Op=operation, D=decommissioning
Legend:
Comp: Company;
EMS: Env. Mgmt System
EMP: Env. Mgmt Project
EML: Env. Mgmt Laws
EMSt: Env. Mgmt Standards
EMC: Env. Mgmt Consultants;
EPA: Env. Protection Agency
NGO: Non-Gov’t Organisation
BU: Business Unit
AF: Assessment Framework
RF:
Reporting Framework
SP:
Sustainability Principles
Gvt: Government
AU: Auditor
CL: Client
: Possible scenario
Figure 5. Business model showing relations of relevant entities in the context of their life cycles.
Modelling Additional Aspects: Decisional and Organisational Models
The formalism selected for the decisional / organisational aspect allows to present essential concepts
present in the design and implementation of an EMS (e.g. as specified in ISO 14001:2004) in an
integrated manner (see Figure 6). The GRAI-Grid is based on Decision Centres (DCs) that operate within
11
Engineering the Sustainable Business: an EA Approach
Author
the boundaries of Decisional Frameworks (DFs) set by the upper echelon. DCs can provide feedback on
the DFs allocated via information links (IL) to the upper echelon. Planning in GRAI-Grid means
balancing the management of resources and products and is represented in the central column of the grid
to reflect its paramount importance. In this particular case, the GRAI-Grid allows to clearly represent the
EMS planning requirements for products, services and activities. Legal requirements, policies, etc can
also be represented as DFs consisting of constraints, objectives (fixed) and decision variables (that the
target DC can manipulate). Horizons and Periods represent the extent of time that the decisions at a
particular level (Strategic, Tactical etc) aim to cover and are to be revised at, respectively.
The resources and products are represented in two columns adjacent to planning. Resources can be
further split into e.g. budget, people and infrastructure, while products can also be subdivided depending
on the specific profile of the company (see Figure 7).
The representation of the DFs will ensure that EM problems are spotted early. Such problems may
include narrow and paternalistic management – whereby EM may be isolated from other relevant
management aspects, or the EM DCs are not given enough authority, respectively. As previously shown,
these are aspects considered essential to the effectiveness of an environmental sustainability initiative and
if neglected may indeed produce a ‘toothless’ EMS, useful to obtain certification to a standard or ease
EPA scrutiny, but not to make the organisation more environmentally sustainable (and thus profitable).
Ext.
Info
Products
Strategic
Resources
Plan
Int.
Info
Decision
Centre
(DC)
Role 3
Horizon
Period
Tactical
Role 4
Horizon
Period
Role 1
Role 2
Operational
Horizon
Period
Control
Legend:
Decision
Framework
(DF)
Information
Link (IL)
Horizon
Period
= decisional centre (DC);
= role;
= decisional framework (DF);
= DFs showing turbulence;
Information
Aggregation
= information flow (IF)
= DFs showing good design
Figure 6. GRAI Grid formalism and notations
A large number of horizontal DFs from the planning DCs to product and resources DCs at all levels
would indicate an interventionist management style (see Figure 6). This is detrimental to the EMS and the
12
Engineering the Sustainable Business: an EA Approach
Author
company as a whole as it involves the Planning DC (sometimes the CxO) spending valuable time ‘putting
out fires’ (resolving urgent, short-term surges and imbalances between resources and production) due to
the incapacity of the DCs to deal with the problem (typically owing to a defective strategy). This
management style creates turbulence and incoherence in the entire organisation as there is no stable and
effective overarching strategy reflecting the EM and other goals. In contrast, vertical DFs indicate that the
DCs can cope with the objectives allocated and the balance is maintained without intervention – i.e. the
organisation (including its integrated EMS) is agile and can thus adapt ‘naturally’ to a certain amount of
changes (including environmentally triggered) in regulations, resource and product requirements.
Communication / information flow is also present in the GRAI-Grid in the columns adjacent to Product
and Resources. Information aggregates in a bottom-up fashion and reaches the DCs via ILs. Thus,
environmental reports for example can be tracked and checked to originate in the right DCs so that they
contain the required information and also reach the intended target DCs so that appropriate corrective
action is taken if required. Direct communication between DCs is achieved via ILs as well (see Figure 6).
Roles can be represented in the GRAI-Grid by areas covering one or more DCs (see Figure 6). The
organisational structure can then be obtained by allocating human resources (HRs) to these roles.
Competence, training and awareness can be represented in the DCs content as HR management; for
example, at strategic level decide on necessary competencies and at tactical level decide on training /
hiring plan. The EMS documentation aspect is reflected in the need to maintain internal information on
each level, e.g. operationally: report, tactically: aggregate reports and trends and strategically: decide on
action plan based on policies, regulations and objectives.
It must be noted that the actual sustainability issues are instances of objectives – therefore the GRAIGrid in fact shows DFs that consist of types of objectives, constraints and decision variables, which define
the management roles. These types are instantiated when implemented (in every period, or if triggered by
a significant event); thus, the instances of objectives can be different from time to time. The DC
(management role) has to decide (based on higher level objectives and the inputs it received from the
outside world and EM reporting entity) what the objectives for its horizon are. For example, the constraint
type may be ‘abide by the current emission regulations’, while the constraint instance is the set of actual
values that the current regulations prescribe. The objective type may state ‘abide by current ISO and
country standards’, while the instances are actual current standards.
One may ask: well, what about the organisational culture aspect that triggers behavioural change and
makes changes ‘stick’? The culture is often a consequence of the type of organisational design (who does
what), staff training and management style / strategy. For example, the feedback provided in the
environmental reporting can be used to set a strategy that encourages and rewards excellence in EM and
to implement it at tactical and operational levels.
13
Engineering the Sustainable Business: an EA Approach
Author
Manage…
Manage…
External
Information
Input Products
& Services
Output Products
& Services
Infrastructure /
Technology
Staff
Budget
Internal
Information
Cumulative
Decide EM
Decide EM
Decide new prod &
expenditure /
strategy; Contribute
Contribute to Staffing Infrastructure
Secure EM budget
services strategy
staffing
to revision of
strategy
Strategy; Contrib
allocation
considering
environmantal
policies, procedures
using EM criteria
to pruduction
their enviro impact
reports, long
& processes
tech strategy
term trends
Enviro
Decide prod &
Strategic forecasts,
services sourcing
H=3y Govt policies,
laws, market strategy considering
P=1y
their enviro impact
trends
Market analysis,
Plan &
Coordinate
Decide yearly
EM plan
Contribute to hiring, Manage Renewal
of EM
staff development &
infrastructure;
Distribute allocated
promotion
Evaluate
EM budget
using EM principles
production
technology
Propose prod &
Tactical yearly forecasts, services sourcing Propose Marketing
public enviro
approach and
(supply chain)
H=1y
reports,
approach considering product revisions
P=6m
feedback
Performance
evals, product /
environmental
reports,
expenditure, int
enviro audits
Client profiles
env impact
Operational
H=6m
P=2w
Public enviro
reports,
feedback
from public /
NGOs /
EPA / clients
Monitor enviro
aspects of incoming
goods & services
Manage short-tem /
unexpected probs
Schedule EM
activities
Manage unexpected
EM savings /
expenses
Manage unexpected
staff issues (e.g.
unavailability, surge
in demand)
Maintain EM
infrastructure
Monitor
Production
Technology’s
EM performance
enviro
feedback,
events
Control
H=1d
P=real
time
Significant
external
events
Control production
Control Service
N/A
Control budget
N/A
Control
Infrastructure
Significant
internal
events
(e.g. spills)
= info. link (IL);
= decisional framework (DF);
= Enviro manager / Board;
= EMS auditor
H = horizon; P = period
Figure 7. Sample GRAI Grid
ns
o
i
it
ag
an
lM
nm
d
ad
t
en
m
e
ta
en
o
vir
En
g
m
m
ge
a
an
t
en
s
sk
a
t
in
ist
Ex
Figure 8. EM addition to the host company management tasks
14
Engineering the Sustainable Business: an EA Approach
Author
Figure 7 shows a sample GRAI-Grid and Figure 8 shows (symbolically) the way the EM DFs would
overlay the host company management tasks. In practice, DCs need to be further detailed using a
functional model (for example expressed in IDEF0 (NIST, 1993) or UML (Rumbaugh et al., 1999)
activity diagrams), down to the level of understanding of the HR(s) fulfilling the role covering those DCs.
Third Step: The Functional Model
The main deliverable of the third (and last) meta-methodology step is an activity model describing the
creation and operation of the EM project and of the EMS. This is achieved by analysing the life cycle
representation of the entities in Figure 5 and expressing the interactions shown in that figure in terms of
the aspects selected from the chosen MF.
In terms of the first meta-methodology sub-step, the type of deliverable (a method) mandates the
functional aspect. However, to be understood and enacted, the activities represented in a functional model
must be detailed using other aspects and views contained in the MF selected in step two – in this case
management / service, human / machine and software / hardware. The present state will be represented
(sub-step two) and it will be shown in a common diagram with the TO-BE, since the activity model
depicts in fact the transition from the AS-IS to the chosen TO-BE state. As for sub-step three, the IDEF0
language is chosen to represent the functional model and the AI0Win tool (KBSI, 2007) is selected to
support model creation. The choice is justified in the following section, along with a brief generalisation.
Important Side Note: The Benefit of using EA languages and tools in EM tasks
The over-arching and cross-departmental features of EA are reflected in the languages and tools used in
this domain. Families of languages (some integrated by metamodels) and tools aware of the implemented
languages’ syntax and often featuring a common repository underlying all models depicting various
enterprise aspects, provide the premise for integrated development. We have attempted to illustrate the
advantage of using such EA artefacts in the sustainability effort by selecting a sample EA tool and
language for the third meta-methodology step applied to the EM project.
IDEF0 provides for complexity control by implementing multiple model levels. Thus, model
components and levels can be independently developed; however, their interfaces called ICOMS (inputs,
controls, mechanisms and outputs, see Figure 9) must be kept consistent. This essential feature can
enforce coherence and discipline in the EMS life cycle design process. For example, management,
business unit teams and EA personnel can work on various aspects / levels of a model in a (quasi-)
independent fashion, knowing that the overall coherence of the model is preserved at all times. ‘Aware’
tools implementing this language (such as the one selected) will enforce such conditions and
automatically carry through and provide the ICOMS necessary for a particular level.
15
Engineering the Sustainable Business: an EA Approach
Author
Controls
Inputs
C1
C2
(used in activity, but do not
get transformed)
(transformed in
the activity)
Outputs
(results of activity)
I1
Activity
O1
I2
O2
Mechanisms
M1
M2
(who / what makes it happen)
Figure 9. IDEF0 generic model, context level (A-0)
Back to the Method Model: The Context Level
This level provides a bird’s eye view of the EM project and its outcome (i.e. the EMS). Such a simple
model may look trivial; however, it is very useful for high-level management, enterprise architect and
other stakeholders to quickly grasp the big picture and make sure that all the necessary elements are
present, e.g. necessary inputs, adequate resources, mandatory constraints and required deliverables.
Getting a common understanding of ‘what is to be done’ and agreeing upon this overall picture can make
a significant difference in achieving a favourable attitude and commitment towards the EM project.
EM
Laws
Company
Audits
Policies NGOs
Org
Design
principles
EM
Certification
Internal Information
EM Frameworks
Create and
Operate
EMS
EMS
A-0
Management
EA
HR
IT
Group Services
Services
Environmental
Reports
Business
Unit
Staff
Figure 10. Context (A-0) level of the EMS creation and operation model
.
16
NGO
Figure 11. A0 level of the EMS creation and operation model
17
Mgmt
Bus Units
Staff
EM Std
(e.g. ISO14001)
EM
Group
A4
Arch
Design EMS
EM
Reporting
Frameworks
Confirmed
EMS
structure
A3
Requirements
of EMS
EMS Goals
Objectives
Policies
Changes
To Concept
EA Group
Relevant
Entities
Develop
EMS
Concept A2
Company
Policies
EM Ref
Models
Sust
Issues
Identify
sustainability
issues A1
EM
Frameworks
Internal
Info
EM
Principles
EM
Laws
HR
Audits
A5
IT
EM
Transition
Plan
EMS
change
requests
Certification
Audit
Detail
Design EMS
Approved
EMS Arch
Design
Org Design
Principles
A6
Implement
EMS
EMS
Initial
EM
Certifica
Confirmed
tion
EMS
Detailed
Design
Operate
EMS
A7
Env.
Reports
EPA
Audit
EM
Certifica
tion
Surveillance
Audit
Engineering the Sustainable Business: an EA Approach
Author
Engineering the Sustainable Business: an EA Approach
Author
The Second Level
The functional model can be now developed by creating one main activity for each EMS life cycle phase
shown in Figure 5 (see Figure 11 for a potential result). The modelling formalism chosen will assist in
developing the model as each activity represented must be investigated for content, inputs, outputs,
controls and resources that execute it.
The Third and Further Levels
The third (and lower) levels are obtained by further decomposing each relevant activity considering
aspects used in previous steps and / or present in the chosen MF, such as human vs. machine and
hardware vs. software (see Figure 12). This will ensure that the EM(S) requirements are represented and
integrated into the business at all necessary levels and aspects. For example, as can be seen in Figure 12,
the decomposition of the Detailed Design activity takes into account proper resourcing of the EMS with
human resources (EM Group, A 5.2) and software / hardware (A5.1). Organisational design will provide
the premise for organisational culture change while the partial redesign of the IS (A 5.3) can enable it to
provide timely and appropriate type of information for the strategic integration of the EM in the business.
Approved
Company EMS Arch.
Policies
Design
Org. Design
Principles
EM
Standards
Certification
Audit
ISO 14001
Info on
exist. IS/IT
infrastructure
EMS Equip / Sw
Detailed Design
ISO 14001
Design EMS
Equipment /
Software A5.1
EM Ref
Models
ISO/DIS
26000
Info on
present
Org. roles
HR Transition Plan
Design Human /
Organisational
Structure A5.2
EM Ref
Models
Info on
existing IS/IT
infrastructure
Human / Organis.
structure Design
(incl. EM Group)
IS Equip / Sw.
Transition Plan
Re-design IS
Equipment /
Software A5.3
IS Equip / Sw.
Detailed Design
EM Ref
Models
Proposed
Detailed Designs
Proposed
Transition Plans
EM
Group
Transition
to EM
Plan
Confirm Detailed
Design, Transition
plans
A5.4
IT
Services
EA
Group
HR
Services
Mgmt
Bus Unit
Staff
EMS
Confirmed
Detailed
Design
Initial
Certification
Figure 12. One of the A1 levels (Detailed Design) of the EMS creation and operation model
18
Engineering the Sustainable Business: an EA Approach
Author
How far will the decomposition go? The activities must be detailed down to the level where they are
understood and thus can be executed by the human(s) and/or machine(s) that need to perform them.
A full decomposition of the example is beyond the purpose of this chapter, which aims to introduce the
approach and test the concept rather than to perform a complete design of the EMS. In addition, each
business is different; therefore, additional specific information is required to enable deeper level
decompositions. For the interested reader, several worked examples are contained in (Noran, 2008).
CONCLUSION
Environmental sustainability and EM are no longer pursued only following law suits, or to appease NGOs
and alleviate scrutiny by EPAs. Companies are realising the financial benefits of environmental
sustainability; EM is becoming a commodity (Molloy, 2007). However, currently there seem to be several
issues that prevent the business from achieving maximum return from implementing and operating a
concerted approach to EM. Firstly, there seems to be a lack of integration of the EM initiative in the
business, especially at the strategic level - meaning that the management cannot take advantage of the
knowledge present in the environmental reporting, either due to the wrong format and/or level of
aggregation, or due to stale data content - hence the need for automation and an integrated IS architecture.
Secondly, the EMS needs to be driven internally and permeate all areas of business in a consistent manner
in order to produce organisational culture change ensuring lasting effects.
In this chapter we have argued that that these needs are best addressed by integrating EM in the ongoing
EA initiative present in one form or another in every successful and agile enterprise. EA can provide the
necessary artefacts and the prerequisites for a coherent, cross-departmental and culture-changing
approach ensuring business sustainability and profitability in the long term.
REFERENCES
Aust. Dept. of Environment and Heritage. (2003). Corporate Sustainability - an Investor Perspective: The Mays
Report. Available: http://www.environment.gov.au/settlements/industry/finance/publications/maysreport/pubs/mays-report.pdf.
Bernus, P., Noran, O. and Riedlinger, J. (2002). Using the Globemen Reference Model for Virtual Enterprise Design
in After Sales Service. In I. Karvoinen and R. van den Berg and P. Bernus and Y. Fukuda and M. Hannus and I.
Hartel and J. Vesterager (Eds.), Global Engineering and Manufacturing in Enterprise Networks (Globemen). VTT
Symposium 224 (pp. 71-90). Helsinki / Finland.
Blackburn, W. R. (2007). The Sustainability Handbook. Cornwall, UK: EarthScan Publishers.
CIMOSA Association. (1996). CIMOSA - Open System Architecture for CIM,. Technical Baseline, ver 3.2. Private
Publication.
Clayton, A. and Redcliffe, N. (1998). Sustainability - A Systems Approach. Edinburgh: Earthscan Publications, Ltd.
Coglianese, C. and Nash, J. (Eds.). (2001). Regulating from the Inside: Can Environmental Management Systems
Achieve Policy Goals? : RFF Press.
DoD Architecture Framework Working Group. (2003). DoD Architecture Framework (Vol I-II; Deskbook). US
DoD. Available: http://aitc.aitcnet.org/dodfw/ [2003, 2004].
19
Engineering the Sustainable Business: an EA Approach
Author
Doucet, G., Gotze, J., Saha, P. and Bernard, S. (2008). Coherency Management: Using Enterprise Architecture to
Achieve Alignment, Agility and Assurance. Journal of Enterprise Architecture, 4(2), 9-20.
Doumeingts, G. (1984). La Methode GRAI [PhD Thesis]. Bordeaux, France: University of Bordeaux I.
Doumeingts, G., Vallespir, B. and Chen, D. (1998). GRAI Grid Decisional Modelling. In P. Bernus and K. Mertins
and G. Schmidt (Eds.), Handbook on Architectures of Information Systems (pp. 313-339). Heidelberg: Springer
Verlag.
Elkington, J. (1998). Cannibals with Forks: The Triple Bottom Line of 21st Century Business.
EPA. (2008). Management Tools. Environmental Protection Agency, South Australia. Available:
http://www.epa.sa.gov.au/tools.html [2008, Jun 2008].
GRI. (2002). Sustainability Reporting Guidelines. In Global Reporting Initiative (Ed.), Sustainability Reporting
Framework: Global Reporting Initiative.
ISO. (2000). Annex C: GERAM, ISO/DIS 15704: Industrial automation systems - Requirements for enterprisereference architectures and methodologies: International Standards Organisation.
ISO. (2004). ISO 14001:Environmental management systems - Requirements with guidance for use: International
Standards Organisation.
ISO/IEC. (2007). ISO/IEC 42010:2007: Recommended Practice for Architecture Description of Software-Intensive
Systems (IEEE1471).
Kalpic, B. and Bernus, P. (2006). Business process modeling through the knowledge management perspective.
Journal of Knowledge Management, 10(3).
KBSI. (2007). AI0Win Software Product, [White Paper]. Knowledge Based Systems, Inc. Available:
http://www.kbsi.com/Software/KBSI/AI0WIN.htm [2007, Apr 2007].
Mo, J. (2007). The use of GERAM for Design of a Virtual Enterprise for a Ship Maintenance Consortium. In P.
Saha (Ed.), Handbook of Enterprise Systems Architecture in Practice (pp. 351-366). Hershey, USA: IDEA Group.
Molloy, I. (2007). Environmental Management Systems and. Information Management – Strategic- Systematical
Integration of Green Value Added. In J. M. Gómez and M. Sonnenschein and M. Müller and H. Welsch and C.
Rautenstrauchm (Eds.), Information Technologies in Environmental Engineering ITEE 2007 - (porceedings of the
3rd International ICSC Symposium).
Nilsson, I. (2001). Integrating Environmental Management to Improve Strategic Decision-Making. Chalmers
University of Technology, Götteborg, Sweden.
NIST. (1993). Integration Definition for Function Modelling (IDEF0) (Federal Information Processing Standards
Publication 183): Computer Systems Laboratory, National Institute of Standards and Technology.
Noran, O. (2003). A Mapping of Individual Architecture Frameworks (GRAI, PERA, C4ISR, CIMOSA, Zachman,
ARIS) onto GERAM. In P. Bernus and L. Nemes and G. Schmidt (Eds.), Handbook of Enterprise Architecture (pp.
65-210). Heidelberg: Springer Verlag.
Noran, O. (2004a). A C4ISR Reference Architecture Assessment using GERA. In O. Vasilecas and A. Caplinskas
and W. Wojtkowsji and W. G. Wojtkowsji and J. Zupancic and S. Wrycza (Eds.), Advances in Theory, Practice and
Education (Proceedings of the 13th International Conference on Information Systems Development (ISD2004)) (pp.
47-58). Vilnius: Vilnius Geminidas Technical University.
Noran, O. (2004b). A Meta-methodology for Collaborative Networked Organisations. Unpublished Doctoral Thesis,
School of CIT, Griffith University.
Noran, O. (2004c). A Meta-methodology for Collaborative Networked Organisations: A Case Study and
Reflections. In P. Bernus and M. Fox and J. B. M. Goossenaerts (Eds.), Knowledge Sharing in the Integrated
Enterprise: Interoperability Strategies for the Enterprise Architect (pp. 117-130). Toronto / Canada: Kluwer
Academic Publishers.
Noran, O. (2005a). An Analytical Mapping of the C4ISR Architecture Framework onto ISO15704 Annex A
(GERAM). Computers in Industry, 56(5), 407-427.
Noran, O. (2005b). Managing the Collaborative Networks Lifecycle: a Meta-methodology. In A. G. Nilsson and R.
Gustas and W. Wojtkowski and W. G. Wojtkowski and S. Wrycza and J. Zupancic (Eds.), Advances in Information
Systems Development - Bridging the Gap between Academia and Industry (Proceedings of the 14th International
20
Engineering the Sustainable Business: an EA Approach
Author
Conference on Information Systems Development (ISD 2005)) (Vol. 1, pp. 289-300). Karlstad, Sweden: Kluwer
Academic Publishers.
Noran, O. (2007a). A Decision Support Framework for Collaborative Networks. In L. Camarinha-Matos and H.
Afsarmanesh and P. Novais and C. Analide (Eds.), Establishing the Foundation of Collaborative Networks
(Proceedings of the 8th IFIP Working Conference on Virtual Enterprises - PROVE 07) (pp. 83-90). Guimaraes /
Portugal: Kluwer Academic Publishers.
Noran, O. (2007b). Discovering and modelling Enterprise Engineering Project Processes. In P. Saha (Ed.),
Enterprise Systems Architecture in Practice (pp. 39-61). Hershey, USA: IDEA Group.
Noran, O. (2008). A Meta-methodology for Collaborative Networked Organisations: VDM Verlag.
Rumbaugh, J., Jacobson, I. and Booch, G. (1999). The Unified Modelling Language Reference Manual. Reading,
MA: Addison-Wesley.
Saha, P. (2007). A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM
(ISO15704:2000 Annex A). In P. Saha (Ed.), Enterprise Systems Architecture in Practice (pp. 1-17). Hershey, USA:
IDEA Group.
Scheer, A.-W. (1999). ARIS-Business Process Frameworks (3rd ed.). Berlin: Springer-Verlag.
Shewhart, W. A. (1986). Statistical Method from the Viewpoint of Quality Control: Dover Publications.
The Open Group. (2006). The Open Group Architecture Framework, (TOGAF 8.1.1 'The Book') v8.1.1.
TNEP. (2007). The Engineering Sustainable Solutions Program Whole Systems Design Suite. The Natural Edge
Project (TNEP). Available: http://www.naturaledgeproject.net/.
UN World Commission on Environment and Development. (1987). Our Common Future (Brundtland Report).
Oxford: Oxford University Press.
Upham, P. (2000). An assessment of The Natural Step theory of sustainability. Journal of Cleaner Production, 8(6),
445-454.
Willard, B. (2002). The Sustainability Advantage: Seven Business Case benefits of a Triple Bottom Line. Gabriola
Island: New Society Publishers.
Williams, T. J. (1994). The Purdue Enterprise Reference Architecture. Computers in Industry, 24(2-3), 141-158.
Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276-292.
21
Download