On the Interplay of Organizational Archi - Alexandria (UniSG)

Enterprise Modelling and Information Systems ArchitecturesVol. 3, No. 1, Month 2008

Wojciech Ganczarski, Robert Winter24

Wojciech Ganczarski, Robert Winter

On the Interplay of Organizational Archi-tecture and Software Architecture

Enterprise architecture frameworks sometimes provide an additional architectural layer between business-oriented artefact types (e. g., business processes, organizational units) and technical artefact types (e. g., softwarecomponents, data structures). This "integration" or "alignment" layer is intended to bridge the gap, which resultsfrom different life cycles, different ownerships, and other sources of IT/business misalignment. The development ofspecific models and artefact types on the integration layer is in its early stage. Existing methods for informationsystems design constitute a first starting point. However, most of them lack a clear differentiation between theintegration layer and the software layer and therefore cannot be reused as-is. This paper contributes to the researchof design methods, models, and artefact type specifications for the integration layer. The focus lies primarily on thealignment of organizational architecture and structural software architecture, two important components ofenterprise architecture. A comparison of organizational and software architecture design methods yields that bothtypes of structures are usually constructed according to different design criteria so that un-aligned architecturesresult. Traditional integration artefacts, such as "logical" applications, which specify coherent areas of ownership oversoftware artefacts, are too closely linked to actual software system structures and therefore usually fail in aligningwith the organizational architecture. It is argued in this paper that instead, integration artefacts should be muchmore decoupled from actual software structures.

1 Introduction

The lack of alignment between information systemsand their corresponding business environment is seenas one of the root causes for why today's companiesare not able to realize value from their IT investments[HeVe93]. By focusing on the interplay of organiza-tional architecture and structural software architec-ture, this paper concentrates on a subset of themultifaceted IT/business alignment problem. Organi-zational architecture is understood as the fundamen-tal organization of activities and decision rights overcorporate assets. Structural software architecture isunderstood as the fundamental organization of soft-ware systems (or business applications as a specificclass of software systems).

By looking at a company's structural software archi-tecture, it is often possible to tell the industry thecompany is operating in, or to generate first hypoth-eses about the company's business model. However,it is much less straightforward to conclude the com-pany's organizational architecture. Why is it thatorganizational architecture and structural softwarearchitecture are usually so different? According toOrlikowski and Barley [OrBa01], structural

differences between organizational and softwarestructures can be attributed to epistemological differ-ences of information systems (IS) research andorganizational research. Whereas IS research focuseson the functioning of engineered artefacts, organiza-tional research is more concerned with the interrela-tions of human behaviour [OrBa01]. Enterprisearchitecture frameworks, which acknowledge thosestructural differences explicitly foresee a specificarchitectural "integration" or "alignment" layer whichis comprised of models that link business-relatedarchitectures with technical architectures. A simpleownership allocation model (OAM), which specifiesthe decisions rights of organizational units over indi-vidual software artefacts, is one example for such anintegration model. Beyond ownership, informationexchange constitutes a further relationship that canbe found between the business and the IS environ-ment. Other types of integration models can thereforebe utilized to ensure alignment in terms of informa-tion exchange.

Whereas the information exchange relationship hasalready been thoroughly analyzed in the work of otherauthors (e. g., see [Wall96]), only few contributionshave been dedicated to the ownership relationship.

Enterprise Modelling and Information Systems ArchitectureVol. 3, No. 1, Month 2008On the Interplay of Organizational Architecture and Software Architecture 25

Therefore, the goal of this paper is to analyze theeffectiveness of existing integration models, espe-cially OAMs based on "applications", and to proposemodifications to those models in order to enhance thealignment between the business and the IS environ-ment. But before those models can be analyzed, adetailed understanding of the reasons is necessary forwhich organizational architecture and software archi-tecture structurally diverge.

The paper is organized into six sections. Following thisintroduction, Section 2 discusses related work. InSection 3, the (extended) Business Engineeringframework is introduced which will be used as theframe of reference. Section 4 will provide a compari-son of organizational design and state-of-the-artapproaches for IS and software architecture design.In order to understand the effectiveness of OAMsbased on "applications", the property rights theory isapplied in Section 5. A modification is proposed onhow more effective ownership allocations over soft-ware artefacts could be defined. The paper closes inSection 6 with an outlook on how those insights canbe taken further to support in the development ofeffective integration models.

2 Related Work

The analysis of differences and commonalitiesbetween the design of organizational architecture andsoftware architecture fits into the subject area of IT/business alignment. In 1993, Henderson and Venkat-raman introduced the Strategic Alignment Model[HeVe93], which since then is referred to as thestandard framework for classifying IT/business align-ment issues. They distinguish four individual problemdomains which require mutual alignment: businessstrategy, organizational infrastructure, IT strategy,and IT infrastructure. Within this framework, theorganizational architecture constitutes one piece ofthe organizational infrastructure, whereas the soft-ware architecture belongs to the IT infrastructure.The question under analysis within this paper cantherefore be assigned to the problem domain of align-ing organizational infrastructure and IT infrastructure.While proposing roles and responsibilities, Hendersonand Venkatraman do not provide a specific alignmentmethod.

Further work which deals with the alignment problemcan be found within the subject area of IT Govern-ance, a term coined by Weill and Ross in 2004[WeRo04]. Weill and Ross define IT Governance as anact of specifying the decision rights and the account-ability framework to encourage desirable behaviour inusing IT [WeRo04]. They distinguish between deci-sions concerning IT principles, IT architecture, ITinfrastructure strategy, business application needs,

and IT investments [WeRo04]. Through an analysis ofIT Governance processes in 300 international compa-nies, they found a correlation between "good" IT Gov-ernance and enterprise performance [WeRo04].Although various best practice examples for effectiveIT Governance processes are provided in their work,Weill and Ross do not propose specific integrationmethods or models which could help companies inactually defining and monitoring IT decision rights.

With respect to the work of Weill and Ross, this paperwill focus on the analysis of business application deci-sion rights which empower organizational units tobuy, build, or adapt individual business applications[WeRo04]. Ownership as it is used here refers to amandate which is granted to organizational units bythe top management. It empowers the grantees tomake decisions about buying, building or adaptingindividual business applications and makes themaccountable for the effective use of these resources.

According to Weill and Ross, those decision rights arethe least mature and also least understood withintoday's companies. Once allocated badly, they maylead to redundant system capabilities, wastedresources, and excessive time to market.

3 Modelling Enterprise Architec-tures

3.1 The business engineering framework

Business Engineering (BE) [ÖsWi03] constitutes acomprehensive and integrated approach to the de-sign and evolution of business architecture, organiza-tional architecture, and IT architecture. Due to itsfocus on consistent "business-to-IT" design, BE isadopted as the terminological and methodologicalfoundation for this paper. The initial BE framework asdescribed by [Wint03a] consists of three major archi-tectural layers: strategy, organization, and IS. In par-ticular the IS layer has been extended and detailed byrecent work of, e. g., Schelp and Schwinn [ScSc05].This paper is based on the five-layer extension of theBE framework which comprises the following architec-tural layers:

The strategy layer represents the business architec-ture which positions the company (or business unit, orcompany network) according to market needs andcompetencies. It provides specifications of products /services and organizational goals from a strategicperspective [BrWi05]. Design criteria for the businessarchitecture can be derived from different approachesto strategic management [WiFi07].



On the organization layer, the static and dynamicorganization of service development, service creation,and service distribution are represented [WiFi07]. Theorganization layer can be subdivided into the processarchitecture which provides specifications for busi-ness processes, and the organizational architecture,which specifies individual organizational units, theirrelationships and key performance indicators[BrWi05]. Major design principles for this layer areeffectiveness and efficiency [WiFi07].

On the integration layer, IS components are organ-ized in the relevant enterprise context [WiFi07]. Theintegration layer represents the fundamental depend-encies and links between IS components (or softwareartefacts, such as software components and datastructures) on the one hand and business require-ments (specified by processes, organizational units,responsibilities, performance indicators, and informa-tional flows) on the other hand [BrWi05]. Integrationarchitecture design focuses on agility, cost efficiency,integration, and speed [WiFi07], but may also beaimed at transparency, consistency, and/or simplifi-cation.

The software layer can be subdivided into the struc-tural and the behavioural software architecture. Thestructural software architecture represents the funda-mental organization of software artefacts, such assoftware components and data structures [WiFi07],which altogether form software systems. Softwarecomponents can be installed, configured, and exe-cuted whereas data structures can be stored,retrieved and manipulated. Software services consti-tute specific software components which are designedaccording to W3C Web Services design standards.Beyond that, the behavioural software architecturerepresents dynamic aspects, such as data flows orinteractions of software components, services or sys-tems. The general design goals for this architecturallayer are high reuse of software artefacts [BrWi05] aswell as minimization of data redundancies [ScSc05].

The infrastructure layer represents the organiza-tion of computing and telecommunication hardware[WiFi07]. Design criteria on this layer are, e. g., effi-ciency of resource usage, robustness, and scalability.

The explicit separation of the integration and the soft-ware layer constitutes one of the major characteris-tics of the extended BE framework. It is motivated bythe notion of the business environment (representedon the strategy and on the organizational layer) andthe IS environment (represented on the software andon the infrastructure layer) as two separate, self-con-tained systems connected via a provider-consumer-relationship. Within this relationship, the IS environ-ment provides services to the business environment.

As good practice, general systems theory proposes toshield the internal design of the provider system fromthe consumer system so that changes of the pro-vider's internal design are not propagated to the con-sumer [AiWi08] and the overall system'smanageability is enhanced. This shielding, alsoreferred to as loose coupling, can be achieved throughthe introduction of an additional abstraction layerbetween both systems. This abstraction or integrationlayer (technically spoken) offers a stable interface tothe consumer, translates consumer requests into theinternal design of the provider, and finally transformsthe provider's response back into the format of thestable interface. Such an integration layer is not onlycapable of buffering changes of IS environment andprevent adoptions on the business environment, butalso vice versa [ScWi07b]. Due to significant differ-ences in innovation cycles of organizational artefacts(lifetimes of up to 2 years) and software artefacts(lifetimes of more than 10 years) [BrWi05], bufferingchanges from each of the layers becomes a crucialcapability for IT/business alignment.

This loose coupling can be compared with the loosecoupling introduced by the Java Virtual Machine(JVM), which allows to port software systems seam-lessly between multiple hardware platforms. Here,changes of the hardware platform are fully bufferedthrough the JVM and not propagated to the softwaresystem. Key to the JVM is that it offers the consumer(or software system) the Java programming languageas a stable, hardware-independent interface towardsthe services of any specific hardware platform.

Similarly as the JVM, the integration layer requires astable interface which is comprised of artefacts thatencapsulate the internals of the software layer andthat can be referenced by the organizational layer.Artefacts, such as logical applications, which will bedetailed in the following paragraphs, are already inuse today. It is however argued in this paper thatthose artefacts and corresponding interfaces are notsufficiently shielding the organizational layer from theinternals of the software layer and therefore need tobe adapted.

3.2 Information systems, business applications and logical applications

The precise understanding of what constitutes an"information system" compared to an "application",and a "software system" varies considerably.

According to Ferstl and Sinz, an information system isdefined as a set of communicating corporate objects,which work on or deal with information resources[FeSi95]. Those corporate objects can be either ofmanual or automated type. Human beings representmanual corporate objects whereas automated


corporate objects are implemented within businessapplications. The term "application" is sometimes alsoused in a slight different context. For example, the BEframework regards applications as logical constructswhich link implemented IS functionalities and infor-mation subjects to joint business ownership andrespective activities ([BrWi05] or [ScSc05]). Thoseapplications are specified as components of applica-tion architecture [WiFi07], which itself constitutes acomponent of the integration layer. But how do theseunderstandings of business applications and applica-tions match with each other?

Business applications are specific software systemswhich implement corporate objects. They consist ofsoftware artefacts and can be ascribed to the softwarelayer. Their fundamental organization is specifiedwithin the software architecture, which is part of theIS architecture. In comparison to business applica-tions, other types of software systems may for exam-ple provide solely infrastructure services withoutimplementing specific corporate objects.

Compared to that, applications that define ownershipareas are logical constructs and belong to the integra-tion layer. To avoid misunderstandings in the follow-ing, we will explicitly designate these constructslogical applications. Logical applications are not com-posed of software artefacts and therefore can be nei-ther installed, configured nor executed. Instead, theyare linked to software artefacts on the one hand andbusiness artefacts on the other hand. Due to theirrelational nature, logical applications are capable ofrepresenting organizational ownership of softwareartefacts.

For many state-of-the-art IS design methods, the"software" and the "logical" view of an application istightly coupled. Either the structure of a businessapplication automatically determines the structure ofa logical application or vice versa (1:1 relationship).Sometimes, logical applications refer to a set of busi-ness applications, while the structure of all businessapplications jointly again determines the logical appli-cation (1:n relationship). A n:m relationship, whichwould allow to structurally decouple software archi-tecture from integration architecture is not foreseenwithin those approaches.

4 Comparing Organizational and Software Architecture Design

4.1 Organizational design

Organizational design is concerned with the structur-ing of goal-oriented social systems [HiFU94]. Theneed for structuring a social system stems from the

limited information processing and problem solvingcapacities of individual human beings, a phenomenonalso referred to as the "organization problem"[Fres05]. Two basic types of structures for the organ-ization of a social system are usually distinguished: astatic organizational architecture and a dynamic pro-cess architecture [Schr96].

Companies are specific social systems whose per-formance considerably depends on the quality of theirorganizational design [Mack86]. Hill et al. point outthat the evaluation of any organizational designtherefore needs to be conducted on the basis of howwell the design supports overall performance[HiFU94]. Frese proposes to evaluate an organiza-tional structure against two major criteria: a) its coor-dination efficiency, and b) its motivational efficiency[Fres05]. Coordination efficiency is primarily con-cerned with the efficiency of a corporate system toutilize its resources and potentials, whereas motiva-tional efficiency focuses on how well the system isable to motivate individual human beings to maximizetheir performance. Hill et al. also differentiate twobasic evaluation criteria that are very similar to thoseof Frese, which they call productivity and socio-emo-tional satisfaction [HiFU94].

But how are organizational architectures actually con-structed? According to Hill et al. [HiFU94], tasks,competencies, and responsibilities constitute the fun-damental structural elements of static organizationaldesign [HiFU94]. Those fundamental elements aregrouped within organizational units, departments,and divisions, which itself are linked within hierar-chies. Multiple forms of structuring exist. For exam-ple, Hill et al. differentiate four approaches: a)functional structuring, b) object-oriented (or divi-sional) structuring, c) regional structuring, and d)phase-oriented structuring [HiFU94]. Functionalstructuring results in functionally oriented organiza-tional units. Object-oriented structuring is primarilyconcerned with the objects that tasks are performedupon. Those objects can be, e. g., product lines orcustomer segments [HiFU94]. There are differentopinions on what is exactly meant by object-orientedstructuring. Whereas Hill et al. [HiFU94] as well asFrese [Fres05] only consider product and market seg-ment based structuring as object-oriented, forSchreyögg [Schr96] regional structuring constitutes afurther sub-type of an object-oriented structuring. Incontrast to that, Hill et al. see regional structuring asa separate dimension. Finally, phase-oriented struc-turing distinguishes between tasks, competencies,and responsibilities that are either related to the plan-ning, execution, or monitoring phase of an enter-prise's value generation process.

In addition to the formation of organizational units, acoordination mechanism which defines the basis fortheir collaboration needs to be put in place. Two



separate coordination paradigms can be distin-guished. On the one hand, hierarchical coordinationorganizes units as a hierarchy which empowers indi-vidual units to govern and coordinate its subordinatedunits. On the other hand, market coordination estab-lishes internal markets within a company which coor-dinate relationships between organizational unitsprimarily on the basis of an internal market prices[Fres05].

Even though market coordination concepts, such asprofit-centres or agreements on transfer prices arewidely used, hierarchical coordination can be stillregarded as the primary coordination mechanismemployed in today's companies. The deployment ofmarket mechanisms as coordination mechanismswithin a company has its clear limitations which origi-nate in the nature of a firm as described by Coase[Coas37]. Thus, companies are required to realizeinternal scale effects in order to stay competitive. Thislimits the number of potential partners as well as thenegotiation power within internal market relationships[Fres05].

According to Frese, hierarchically coordinated func-tional, divisional, and regional forms of structuringsuffice to describe most of the organizational struc-tures of today's companies. Frese also provides a firstcomparison of those three forms of structuring withrespect to the design criteria of coordination andmotivational efficiency. Functionally structuredorganizations require high coordination between indi-vidual organizational units, because most of the busi-ness processes span across multiple organizationalunits [Fres05]. However, functionally grouped organ-izations provide a high efficiency with respect toresource utilization and utilization of market opportu-nities, because resources that are required for thoseactivities are bundled within the same unit [Fres05].Divisionally structured organizations enable organiza-tional units to act with high autonomy [Fres05] and,as an immediate consequence, maximize individualresponsibility and therefore motivational efficiency.

Schreyögg adds that a divisional (or object-oriented)organizational design enhances manageability and ismore result-oriented than a functional design[Schr96]. On the other hand, resource efficiency islower in a divisional structure, because resources,which are required to execute similar or identical busi-ness processes are not pooled (like in a functionalsetup), but rather need to be replicated for each divi-sion [Fres05]. Finally, the main advantage of aregionally structured organization is a high focus onmarket efficiency. However, similar to the divisionalsetup, a regional organization requires a replication ofresources which reduces resource efficiency [Fres05].

Table 1 summarizes the described design criteria andforms of structuring for organizational design.

4.2 Information systems design

Compared to organizational design, the discipline ofIS design has not yet agreed on a specific set ofdesign criteria and a well-defined system of structur-ing types. This could be ascribed to the differentmaturity levels of both disciplines. Therefore, designcriteria and forms of structuring need to be extractedout of representative state-of-the-art approaches forIS design. The following three approaches have beenselected for the analysis:

• IBM's Business Systems Planning (BSP)method [Zach82]

• IMG's Promet Systems and Technology Plan-ning (STP) method [IMG99]

• Winter's application architecture model[Wint03b]

Business Systems Planning (BSP): The BSPmethod supports in the construction of a high-level ISarchitecture. This architecture is comprised of individ-ual "applications" that are determined by their func-tional scope (see [Wint03b] and [IBM84]). Those BSP

Architectural layer

Partial archi-tecture in focus

Design criteria Forms of structuring

Organization layer

Organizational architecture

- Coordination efficiency - By functions - By products - By market segments - By regions - By phases

Market effectiveness

Resource efficiency

Process efficiency

Delegation efficiency

- Motivational efficiency and effectiveness

High responsibility

High manageability

High market pressure

Table 1: Summary for the organizational design analysis


applications simultaneously define structures forownership areas, which are assigned to organiza-tional units (i.e., logical applications), but also set thefoundation for the structure of individual businessapplications. The BSP method is based on a matrix,which represents dependencies between businessprocesses and data clusters. Areas with a high densityof dependencies define the functional scope of individ-ual BSP application candidates (see [Wint03b] and[IBM84]). Structuring BSP applications along dataclusters intends to ensure data consistency and toavoid data redundancies [Zach82], because, whenstructured along data clusters, (business) applica-tions define and store data structures uniquely withintheir own boundaries. On the other hand, structuringBSP applications along business processes shallreduce integration complexity, because there are fewdata handovers across multiple (business) applica-tions. This is due to the fact that the majority of infor-mation flows within a company occurs betweenindividual activities belonging to the same businessprocesses.

Promet Systems and Technology Planning(STP): Similar to BSP, the Promet STP approach con-structs a high-level IS architecture by defining thefunctional scope of individual "applications". Again,STP applications simultaneously define the structurefor business applications as well as for ownershipareas (i.e., logical application). In comparison to BSP,the STP method uses a matrix comprising businessunits on the one axis and functionality clusters on theother axis. This matrix is primarily intended to docu-ment functionality ownership within a given organiza-tional architecture. STP application candidatesdescribe high-density areas of functional ownership(see [Wint03b] and [IMG99]). (Business) applicationsstructured along functionality clusters ensure a highreuse of functionality. On the other hand, (logical)applications, which are structured along businessunits, ensure clarity of the ownership structure and asustainable organizational embedding [Wint03b].

Winter's application architecture model: Winterfound that the BSP and Promet STP methods are com-plementary to each other and proposed to mergethem within a three-dimensional architecture model[Wint03b]. The architecture model is defined alongthree dimensions: Functionality clusters, informationsubjects, and business processes [Wint03b]. Struc-turing (business) applications along functionality clus-ters shall enhance reuse of functionality. Informationsubjects correspond to data clusters used in the BSPapproach and structuring along those shall enhancedata consistency. The third dimension is assumed torepresent business processes jointly with organiza-tional units. Winter assumes that the dimension ofbusiness processes and that of organizational unitscould be merged [Wint03b].

Most of the presented approaches for IS design pre-sume a tight link between the structures of logicalapplications, which define ownership areas on the onehand and business applications that represent actualsoftware systems on the other hand. The objective ofthe presented design methods is to define an IS archi-tecture that fulfils two goals simultaneously: 1) tosatisfy technical needs of the software architecture,and 2) to ensure an efficient integration into theorganizational context. BSP, STP, and Winter's pro-posal are therefore highly influenced by design crite-ria from pure software architecture design.

This also implies that design criteria used by thoseapproaches cannot be automatically assigned toeither the integration or the software architecturelayer. We argue that except for the clarity of owner-ship, all remaining design criteria and structuringdimensions should be assigned to the software archi-tecture layer, since they all have immediate impact onthe efficiency of the software architecture as such.Integration complexity, functional reuse and dataconsistency can be measured within a software archi-tecture even without any knowledge about the organ-izational environment. On the other hand, clarity ofownership clearly requires a link to the organizationalarchitecture.

Assigning the data consistency and functional reusecriteria to the software layer is consistent with the BEframework. On the integration layer, the BE frame-work regards integration complexity as a design crite-rion whereas clarity of the ownership structure is notfound explicitly.

4.3 Software architecture design

Similar as for IS design, design criteria and forms ofstructuring for software architecture design areextracted through the analysis of a state-of-the-artdesign method. The well-known Architecture Trade-off Analysis (ATAM) developed by Kazman et al. hasbeen selected for this purpose [KaKZ00].

Architecture Trade-off Analysis (ATAM): ATAMwas developed by Kazman et al. in 2000 to formallyevaluate individual architectural decisions for soft-ware systems. The evaluation of architectural deci-sions is based on the following predefined qualityattributes: performance, modifiability, availability,and security [KaKZ00]. For each individual architec-ture evaluation project, a utility tree is constructed torate the specific importance of those parameters. Theutility tree is then used to evaluate multiple optionalarchitectural styles and to make a recommendation.The ATAM method complements the previously pre-sented methods since it focuses on aspects that aresolely relevant for the design of software systems,and is not restricted to business applications, as well,



as less concerned with the integration of softwaresystems into the organizational environment.

Table 2 summarizes the design criteria and forms ofstructuring, which have been extracted from the anal-yses of IS design and software architecture designmethods.

4.4 Comparison

A first comparison of Tables 1 and 2 shows that struc-turing along functions constitutes a common form ofstructuring, intended to enhance reuse and avoidredundancies. In addition, data consistency can beunderstood as a specialization of resource efficiencycriteria, because the goal is to avoid multiple storagelocations and therefore synchronization efforts for thesame type of data. Within software architecture, thisgoal is achieved by structuring along information sub-jects. However, no corresponding form of structuringcan be found within organizational design. On theother hand, a structuring along phases, such as plan-ning, execution, and monitoring, is less relevant forsoftware architecture, because software is primarilyused as an executing resource and less for (e. g.,strategic) planning and monitoring activities. More-over, motivational efficiency represents a design cri-terion which is specifically relevant for maximizinghuman resource performance, but has no relevancefor technical artefacts, such as software systems.

Given the assumption that different design criteriaand forms of structuring also lead to different struc-tures, these results can be taken as a starting point toexplain why organizational architecture and structuralsoftware architecture are so different. The analysisshows that both types of structures are usually opti-mized with respect to design criteria that are specificto each structure and overlap only partially.

5 Aligning Organizational and Software Architecture

The previous sections provide a first explanation forthe existence of structural differences between organ-izational and software architecture. Based on thesefindings, the effectiveness of logical applications – aspecific integration and alignment mechanismbetween those two architectural layers – is now ana-lyzed. Later, a modification to this alignment mecha-nism will be proposed in order to enhance itseffectiveness.

5.1 OAM based on logical applications

This paragraph is intended to illustrate how organiza-tional architecture and structural software architec-ture are aligned traditionally using logicalapplications. A conceptual model is introduced inorder to represent the relevant characteristics ofthese architectures. Similar to the BE core metamodel [ÖWH+07], the conceptual model will use UMLclass diagrams as its modelling language (see, e. g.,[Oest05]).

According to the BE framework, an organizationalarchitecture is specified by a set of organizationalunits and their relationships [BrWi05]. Organizationaldesign describes an organizational unit in terms of thecompetencies (or decision rights) that are assigned toit. Among the multitude of competencies which can beassigned to organizational units, a subset empowersindividual units to be responsible for the definition ofbusiness functions or information subjects. Thesetypes of competencies shall be referred to as defini-tion ownerships. On the other hand, structural soft-ware architecture is specified by a set of businessapplications and their relationships. As was describedabove, those business applications group individualsoftware artefacts (software components or servicesand data structures).

Architectural layer

Partial archi-tecture in focus

Design criteria Structuring dimensions

Integration layer Logical application architecture

- Clarity of ownership - By organizational units

Software layer Structural software architecture

- Integration complexity - By business processes - Functional reuse - By functions - Data consistency - By information subjects - Performance - By time critical procedures - Modifiability - By change dependencies - Availability - By high-availability areas - Security - By data security areas

Table 2: Summary for the information systems and software architecture design analysis


Organizational architecture and structural softwarearchitecture can then be connected in the followingway: Business functions are implemented within spe-cific software components, and the content of infor-mation subjects is stored within data structures. Inaddition, competencies on the development of busi-ness applications are grouped within logical applica-tions, which then are assigned to organizational units.These types of competencies will be designated asapplication ownerships in the following.

Figure 1 illustrates this (simplified) conceptual modelof logical applications as traditional integration arte-facts between organizational architecture and struc-tural software architecture.

5.2 Alignment issues for OAM based on logical applications

The intention of this paragraph is to show that anownership allocation solely based on logical applica-tions does not appropriately consider structural differ-ences between the organizational and the softwarearchitecture. In addition, the property rights theory isutilized to illustrate that a lack of addressing thosestructural differences results in economically undesir-able behaviour.

5.2.1 Defining structural differences

What is actually meant by a structural differencebetween organizational architecture and softwarearchitecture? Before structural differences can bedefined, it is first necessary to understand and definestructural equivalence: An organizational architectureand a structural software architecture are regarded asstructurally equivalent, if each of the organizationalunits has ownership over those software artefacts (orfragments) which implement and store exactly thosebusiness functions and information subjects that areunder its definition ownership.

Based on the above definition, a structural differenceis simply defined as any deviation from structuralequivalence. Structural differences occur if businessfunctions or information subjects, which are under thedefinition ownership of a unit A, are implemented orstored within a business application that is owned byunit B. This means that a single business applicationis comprised of software components and data struc-tures that implement business functions and informa-tion subjects of multiple (hierarchically independent)organizational units.

Based on the findings of the third Section of this paperit can be argued that OAMs based on logical applica-tions will inevitably lead to structural differences,because differing design criteria of software andorganizational design will result in business applica-tion structures, which comprise software components

and data structures belonging to at least two (hierar-chically independent) organizational units. In the fol-lowing, a first analysis indicates economicimplications which are caused by those structural dif-ferences.

5.2.2 Foundations of the property rights theory

The property rights theory (PRT) constitutes an eco-nomic theory, which is concerned with the creationand allocation of property rights onto individual eco-nomic actors [Mart00] and is based on the theory ofasymmetrical information. PRT analyses the implica-tions of alternative allocations of property rights[Fees97], which are defined as the sum of all legallypermitted usage rights for a specific resource[Mart00].

According to PRT, the distribution of property rightsdetermines the efficiency of the overall resourceusage [Mart00]. Highest efficiency of resource usagecan only be achieved if each of the economic actorsfully owns the property rights of the resource he orshe is using. Only then economic actors can be fullycompensated or punished based on the effectivenessof their resource usage. As a consequence, they willdeliver their maximal performance [Mart00]. PRTassumes that individuals exploit their possibilities foropportunistic behaviour in the case of shared property

Integrationarchitecture

Organizational unit

Information subject

Businessfunction

Definitionownership

Data structureSoftwarecomponent

Businessapplication

Organizationalarchitecture

Structuralsoftwarearchitecture

Applicationownership

Logicalapplication storesimplements

Figure 1: OAM based on logical applications



rights, when individual behaviour cannot be observed,a specific type of information asymmetry which is alsocalled hidden action [Krae99]. This exploitation allowsfor an individual optimization, but reduces the effec-tiveness of the total resource usage.

Two separate approaches are generally distinguishedon how resource usage effectiveness can beenhanced. One solution is the clear delineation ofproperty rights onto the resource users; the othersolution is the elimination of information asym-metries.

The delineation of property rights requires to setupand control contracts between the involved parties,which itself causes separation costs [Mart00]. On theother hand, information asymmetries, such as hiddenactions, can be addressed with appropriate incentivesystems [Vari99], where parties using a resource arealso compensated or punished on the basis of thetotal resource usage effectiveness.

5.2.3 Structural differences in the light of the property rights theory

The property rights theory is applied here to explaineconomic implications of structural differencesbetween organizational architecture and structuralsoftware architecture. The following case is con-structed: A business application implements businessfunctions and stores information subjects which areunder the definition ownership of two hierarchicallyindependent organizational units A and B. Those twounits share the ownership or property rights over theentire business application, which leads to a structuraldifference as defined in 5.2.1. Each of the units hasthe competence to initiate change projects; moreoverdevelopment and maintenance costs for the businessapplication are shared between both units.

According to the property rights theory, the lesserboth organizational units are able to observe theother parties' behaviour, the higher the incentives foreach of them will be to behave opportunistically at theexpense of the other. The ability to behave opportu-nistically also depends on how good development andmaintenance costs of the business application can beassigned to the causing organizational unit. It isassumed that each unit has its own cost budget andthat assigned development and maintenance costs forthe business application are deducted from that costbudget. Based on this, three scenarios can be distin-guished:

1) Development and maintenance costs are dividedupon both units using a fixed factor, regardless ofthe actual resource usage of both units

2) Development costs are assigned to the causingunit and only maintenance costs are divided uponboth units using a fixed factor

3) Development and maintenance costs are as-signed fully to the causing unit

In case 3) none of the organizational units is able toact opportunistically. However, a fair allocation ofmaintenance costs, sometimes even developmentcosts in the case of one joint business application isusually difficult to achieve. In case 2), both organiza-tional units will behave opportunistically if this behav-iour leads to a reduction of their own total costs at theexpense of the shared maintenance costs. Practi-cally, this could be done by saving development costs,e. g., by advising "quick-and-dirty" solutions whichincur higher long-term maintenance costs. In case 1),organizational units can improve their individual costsituation if they manage to reduce the rest of theircost budget at the expense of development or main-tenance costs, which are then shared with the otherunit. This could for example be done by saving costson the elaboration of functional specifications (whichis done by the organizational unit's own staff) at theexpense of additional development costs.

As this application of PRT shows, structural differ-ences between organizational architecture and soft-ware architecture can have undesirable economicimplications. In the case of shared business

Integrationarchitecture

Organizational unit

Information subject

Businessfunction

Data structureSoftwarecomponent

Businessapplication

n:m n:m

Organizational architecture

Structuralsoftwarearchitecture

Integrationdomain

storesEnterpriseinformation

entity

Enterpriseservice

1:1 1:1

Definitionownership

Definitionownership

Domain ownership

Figure 2: OAM based on integration domains


application ownership, individual organizationalunits are incentivized to behave opportunistically andto reduce their own costs at the expense of the totalbusiness application development and maintenancecosts. According to PRT, this problem can only beomitted if either all information symmetries are elim-inated or if the property rights for the business appli-cation resource are separated. The next paragraphintroduces a new OAM that aims to provide logicalartefacts, which allow to separate property rights forbusiness applications. Those logical artefacts arestructured according to business structures instead ofsoftware structures (such as in the case of logicalapplications).

5.3 A modified ownership allocation model

If the delineation of ownership on the basis of logicalapplications is not suitable, how then should an OAMbe designed that would encourage more efficient eco-nomic behaviour of individual organizational units?

Based on the insights of the former paragraphs, onerequirement for an alternative OAM can be stated asfollows: logical artefacts should allow to assign own-ership over software artefacts (or fragments) that fitswell with or at least approximates the definition own-ership of organizational units implied by the organiza-tional architecture. In other words, such logicalartefacts should be capable of reducing the magni-tude of structural differences as defined in 5.2.1.

The most straightforward way to fulfil this require-ment is to decouple logical artefacts from existingstructures and artefacts of the software layer andstructure them according to the design criteria of theorganizational layer instead. In order to achieve this,the meta model is modified as follows: First, new lo-gical artefacts named enterprise services are intro-duced on the integration layer. Enterprise servicesrepresent implementations of specific business func-tions within software components. They are thereforelinked to business functions using a 1:1 relationship.Enterprise services itself are linked via a n:m relation-ship with software components. A n:m relationship isrequired here, because differing design criteria ofsoftware and organizational design may require oneenterprise service to be implemented within two ormore software components. Conversely, one softwarecomponents may also be used to implement multipleenterprise services.

Moreover, enterprise information entities are intro-duced as further logical artefacts to represent infor-mation subjects which are stored within datastructures. Again, enterprise information entities arelinked to information subjects via a 1:1 relationship,

whereas differing design criteria require a n:m rela-tionship towards technical data structures.

Logical applications are replaced by artefacts namedintegration domains. Those integration domains con-stitute containers of enterprise services and informa-tion entities and are assigned to individualorganizational units in order to define their ownershipover the content of linked software artefacts. Insteadof being granted an application ownership, organiza-tional units are now granted domain ownership. Fig-ure 2 illustrates the adapted meta model of the newownership allocation model based on integrationdomains.

Because enterprise services and information entitiesare structured according to design criteria of theorganizational layer (or can even be seen as structuralcopies of business functions and information sub-jects), integration domains offer ownership areas thatavoid structural differences. In addition, integrationdomains are also independent of the underlying soft-ware architecture and therefore should be robusttowards any technical changes. For example, the con-solidation of several business applications should nei-ther effect the structure of logical artefacts norintegration domains. Instead, changing the links oflogical artefacts to the newly formed consolidatedbusiness applications should suffice to make it con-sistent with the new software architecture.

Beyond a robustness with respect to changes in thestructural software architecture, integration domainsshould also remain stable in cases when the organiza-tional architecture changes. It should therefore beavoided to define integration domains as structuralcopies of existing organizational units. Instead, inte-gration domains should be defined on a more granularlevel so that in case of a restructuring, existing inte-gration domains can be reallocated to the newlyformed organizational units.

The challenge for engineering on the integration layerlies now within making those introduced logical arte-facts actually tangible. Only if logical artefacts can bedelineated from each other, organizational units willaccept them as substitutes for logical applications andthen can be made fully responsible for their develop-ment and maintenance costs.

One possibility to make enterprise service tangible islinking them to a service interface offered on the soft-ware layer (regardless whether this interface isexposed by a monolithic business application or anelementary software service). But linking is also pos-sible when no service-oriented software architectureis in place, e. g., by linking enterprise services tofunctions accessible through the GUI of a businessapplication.



5.3.1 Example

An example shall be provided that demonstrates theapplication of the new OAM in the financials domain.The work of a financial accounting and a managementaccounting unit (both belonging to the finance depart-ment) is supported by a single highly-integrated ERPsystem. Ownership over the ERP system is delineatedbetween both units using integration domains. On theone hand, the financial accounting unit is responsiblefor the two integration domains core bookkeeping andlegal reporting. On the other hand, the managementaccounting unit is responsible for the integrationdomains planning and management reporting. Eachof the integration domains can be broken down toindividual enterprise services. E. g., the legal report-ing domain can be further broken down into the twoenterprise services financial consolidation and finan-cial statements reporting.

Integration domains and enterprise services are inde-pendent of the actual ERP system's software architec-ture. Therefore, even if the underlying softwarestructures changes (e. g., a new version of the ERPsystem is introduced or the provider is switched),enterprise services and integration domain structurescan remain stable and therefore provide the organiza-tional layer a robust and stable reference to the soft-ware layer. However, it is much more difficult todefine integration domains that are also stable withrespect to organizational changes, since not all possi-ble reorganizations can be anticipated upfront. In thegiven example, the definition of the integrationdomains would for example support a reorganizationthat splits the financial accounting unit into a book-keeping and a legal reporting unit without having toredefine the integration domains. However, in case ofany other possible split, the integration domainswould have to be redefined.

6 Conclusion

The results of this paper can be summarized as fol-lows: First, it has been shown that the construction oforganizational architecture on the one hand and soft-ware architecture on the other hand adheres to differ-ent design criteria so that inconsistent structures arecreated. Alignment mechanisms, such as ownershipallocation models (OAMs) are required to align thesedifferent architectures. It has been argued that a tra-ditional OAM for software artefacts on the basis of lo-gical applications creates opportunities for organiza-tional units to act opportunistically which leads tosuboptimal solutions on a company-wide level.

Ownerships over IS artefacts therefore needs to bedefined not on the basis of business applications, buton the basis of logical artefacts that are structuredaccording to organizational design criteria, thereby

more accurately approximating actual ownershipsover business functions and information subjectsimplied by the organizational architecture.

This paper is focused on a rather static alignment oforganizational and software architecture. Furtheranalysis might include dynamic aspects. For example,the flexibility of traditional versus more granularOAMs could be compared in cases where organiza-tional architectures change, but software architectureremains unchanged (at least on a short-term basis).The assumption so far is that an OAM based on logi-cal artefacts will be able to adjust more easily tochanged organizational architectures compared to amechanism based on logical applications. Thishypothesis however needs to be verified by furtherresearch.

References

[AiWi08] Aier, Stephan; Winter, Robert: Virtual Decouplingfor IT/Business Alignment - Theoretical Foundations,Architecture Design and Implementation, ResearchReport, Institute of Information Management, Univer-sity St. Gallen, St. Gallen, 2008, pp. 1-22.

[BrWi05] Braun, Christian; Winter, Robert: A Comprehen-sive Enterprise Architecture Metamodel and Its Imple-mentation Using a Metamodeling Platform. In: Enter-prise Modelling and Information Systems Architectures,Gesellschaft für Informatik, Klagenfurt 2005, pp. 64-79.

[Coas37] Coase, Ronald H.: The Nature of the Firm. In: Eco-nomica, 4 (1937) 16, pp. 386-405.

[Fees97] Feess, Eberhard: Mikroökonomie - Eine spieltheo-retische Einführung, Metropolis-Verlag, Marburg 1997.

[FeSi95] Ferstl, Otto K.; Sinz, Elmar J.: Der Ansatz desSemantischen Objektmodells (SOM) zur Modellierungvon Geschäftsprozessen. In: Wirtschaftsinformatik, 37(1995) 3, pp. 209-220.

[Fres05] Frese, Erich: Grundlagen der Organisation:Konzepte - Prinzipien - Strukturen, 9. Ed., Gabler,Wiesbaden 2005.

[HeVe93] Henderson, John C.; Venkatraman, N.: Strategicalignment: Leveraging information technology fortransforming organizations. In: IBM Systems Journal,32 (1993) 1, pp. 4-16.

[HiFU94] Hill, Wilhelm; Fehlbaum, Raymond; Ulrich, Peter:Organisationslehre 1: Ziele, Instrumente und Bedingun-gen der Organisation sozialer Systeme, 5. Ed., Haupt,Bern et al. 1994.

[IBM84] IBM: Business Systems Planning - InformationSystems Planning Guide, IBM-Form GE20-0527-4, 4.Ed., IBM-Corporation, Atlanta 1984.

[IMG99] IMG: PROMET STP: Methodenhandbuch für dieSystem System- und Technologieplanung, Release 1.0,IMG AG, St. Gallen 1999.


[KaKZ00] Kazman, Rick; Klein, Mark; Clements, Paul: ATAM:Method for Architecture Evaluation, Software Engineer-ing Institute Carnegie Mellon University 2000.

[Krae99] Kräkel, Matthias: Organisation und Management,Neue ökonomische Grundrisse, Mohr Siebeck, Tübingen1999.

[Mack86] Mackenzie, Kenneth: Organizational Design: theOrganisational Audit and Analysis Technology, AblexPublishing Corporation, New Jersey 1986.

[Mart00] Martiensen, Jörn: Institutionenökonomie - DieAnalyse der Bedeutung von Regeln und Organisationenfür die Effizienz ökonomischer Tauschbeziehungen, Ver-lag Franz Vahlen, München 2000.

[Oest05] Oestereich, Bernd: Analyse und Design mit UML 2,7. Ed., Oldenbourg Verlag, München, Wien 2005.

[OrBa01] Orlikowski, Wanda J.; Barley, S. R.: Technologyand Institutions: What Can Research on InformationTechnology and Research on Organizations Learn FromEach Other? In: MIS Quarterly, 25 (2001) 2, pp. 145-165.

[ÖsWi03] Österle, Hubert; Winter, Robert: Business Engi-neering - Auf dem Weg zum Unternehmen des Informa-tionszeitalters, 2. Ed., Springer, Berlin et al. 2003.

[ÖWH+07] Österle, Hubert; Winter, Robert; Höning, Frank;Kurpjuweit, Stephan; Osl, Philipp: Business Engineering- Core-Business-Metamodell. In: WISU - Das Wirt-schaftsstudium, 36 (2007) 2, pp. 191-194.

[ScSc05] Schelp, Joachim; Schwinn, Alexander: Extendingthe Business Engineering Framework for ApplicationIntegration Purposes. In: The 20th ACM Symposium onApplied Computing (SAC2005), ACM Press, Santa Fe,New Mexico 2005, pp. 1333-1337.

[ScWi07b] Schelp, Joachim; Winter, Robert: Towards aMethodology for Service Construction. In: HICSS-40,IEEE Computer Society 2007, pp. 61-67.

[Schr96] Schreyögg, Georg: Organisation: Grundlagenmoderner Organisationsgestaltung, Gabler Verlag,Wiesbaden 1996.

[Vari99] Varian, Hal: Grundzüge der Mikroökonomik, Old-enbourg Verlag, München 1999.

[Wall96] Wall, Friederike: Organisation und betrieblicheInformationssysteme - Elemente einer Konstruktionsle-hre, Gabler, Wiesbaden 1996.

[WeRo04] Weill, Peter; Ross, Jeanne W.: IT Governance -How Top Performers Manage IT, Harvard BusinessSchool Press, Boston 2004.

[Wint03b] Winter, Robert: An Architecture Model for Sup-porting Application Integration Decisions. In: ECIS,Naples 2003.

[Wint03a] Winter, Robert: Modelle, Techniken und Werk-zeuge im Business Engineering. In: Österle, H.; Winter,R. (Hrsg.): Business Engineering - Auf dem Weg zumUnternehmen des Informationszeitalters, 2. Ed.Springer, Berlin et al. 2003, pp. 87-118.

[WiFi07] Winter, Robert; Fischer, Ronny: Essential Layers,Artifacts, and Dependencies of Enterprise Architecture.In: Journal of Enterprise Architecture, 3 (2007) 2, pp.7-18.

[Zach82] Zachman, John: Business Systems Planning andBusiness Information Control Study: A comparison. In:IBM Systems Journal, 21 (1982) 1, pp. 31-53.

Wojciech Ganczarski

Institute of Information ManagementUniversity of St. GallenMueller-Friedberg-Strasse 89000 St. [email protected]

Prof. Dr. Robert Winter

Institute of Information ManagementUniversity of St. GallenMueller-Friedberg-Strasse 89000 St. [email protected]

On the Interplay of Organizational Archi - Alexandria (UniSG)

Documents

Transcript of On the Interplay of Organizational Archi - Alexandria (UniSG)