Paper presented at the First International Workshop on Information SystemsEngineering (WEISE 2007) held in conjunction with DEXA 2007, Regesburg,

Germany, 3-7 September 2007

Adding a Human Perspective to Enterprise Architectures

Zacarias M.1,2, Caetano A. 1,3, Magalhães R. 1,3 Pinto, H. S. ,3,4

Tribolet J. 1,3

1 Center for Organizational Engineering, INESC, Lisboa, Portugal.2 Universidade do Algarve, ADEEC-FCT, Faro, Portugal.

3 Department of Information Systems and Computer Science, IST/UTL, Lisbon, Portugal.

4 ALGOS, INESC-ID, Lisboa, Portugalmzacaria@ualg.pt, artur.caetano@inov.pt, sofia@algos.inesc-id.pt,

jose.tribolet@inov.pt

Abstract

Enterprise modeling, commonly supported byEnterprise Architecture frameworks, has provedto be an effective communication tool thatfacilitates the development of applicationsaligned with the business. These modelingframeworks are concerned with organization’sdesign rather than its actual implementation. Weargue that modeling the actual implementationof organizations can be a valuablecommunication tool not only for systemsdevelopment but also for organizationalanalysts, managers and workers. However, thiskind of usage requires the inclusion of a humanperspective in current enterprise architectures. Inthis paper, we propose to extend the CEOenterprise architecture with a human view basedon a conceptual model consistent withcontemporary paradigms of organizationalscience. The proposal is illustrated with examplesdrawn from a case study.

1. Introduction and Motivation

Enterprise modeling within theInformation Systems (IS) field aimsat supporting the development ofapplications aligned with thebusiness strategy and implementingprocesses. IS models -commonlyreferred as Enterprise Architectures(EA)- enable to model organizationsfrom different, but interrelated,perspectives or viewpoints. EAmodeling languages are intended tosupport communication among ISstakeholders. Hence, these languagesuse syntax and semantics that seek toreduce ambiguities. Current EA frameworks provide semi-formal and graphical means torepresent organization’s structureand processes i.e., aspects of theorganization’s design. The hypothesisof the present research is that EAcan be valuable tools in facilitatingshared understandings of the actualimplementation of organizations,particularly of the specific subjects that

1

fulfill tasks, the specific ways ofperforming these tasks, as well aswhen and where they perform it. Thiskind of information allows uncoveringindividual and collective workpractices. It also provides means ofevaluating how these practices evolvein time. The importance of discovering workpractices to improve user support hasbeen acknowledged in [12]. From ourpoint of view, facilitating graphicaldepictions of actual resource usage,typical interactions is also valuablein (1) discovering problems notdetected by process models, (2)tracing the actual relationship ofworkers with organizational tasks,resources and other workers and (3)assessing the alignment betweendesign and execution. Thus, a betterknowledge of organization’simplementation issues is useful notonly for IS developers but also fororganization analysts and managers.Even individual workers can benefitby having better understandings oftheir contribution to overallbusiness goals and processes.However, capturing and updating thiskind of information requires first,adjusting and extending EA. Second,it is necessary to develop a modelacquisition approach and supportingtools to build and update thecorresponding enterpriserepresentations. This paper addresses the required EAextension. Due to their focus oncapturing organization’s design, EAframeworks provide process-centered,role-based languages that are notconcerned with the particular ways andmeans used by given subjects inperforming their work, the places wherethey perform given tasks or when theyperform them. Neither are they

concerned with how subjects interactwith each other. Capturing humanbehavior requires the inclusion of ahuman perspective in EA. Contemporary models of organizationalsciences regard organizations ascomplex, adaptive socio-technicalsystems, which result from theinteractions among its agents.Moreover, organizational sciencesacknowledge that (1) individualagents themselves are autonomous andcomplex entities that have their owndynamics, (2) agent behavior iscontext-dependent and (3) theoperation and evolution of individualagents and organizations are inter-dependent processes. We argue thatan appropriate representation of thehuman side should be consistent withthese approaches. We also argue thatthe use of semi-formal languages isessential to reduce ambiguousinterpretations.The integration of a humanperspective in EA proposed in thispaper is based on a conceptualframework to model organizations fromthe perspective of its agents that wedescribe in [1]. The goal of thisframework is to facilitate a “reverseengineering” of organizational agentsand their relationships withactivities and resources. Theremaining of this paper is structuredas follows. Section 2 summarizesrelated research on enterprisemodeling. Section 3 summarizes ourconceptual framework. Section 4 showssome examples of this frameworkthrough examples drawn from a casestudy. Section 5 illustrates how thisconceptual framework can beintegrated in enterprisearchitectures. Section 6 gives ourconclusions and future directions.

2

2. Enterprise Architectures(EA)EA are conceptual and methodologicalframeworks used to depict and alignthe organization's strategy with itsbusiness processes and resources.There are several EA providingframeworks to model organizations.Since their essential function is tofacilitate communication betweenIS/IT stakeholders, they aredescribed using more formal syntaxand semantics. Enterprises aredepicted in terms of differentperspectives or views. The most commonlydepicted enterprise perspectives arethe process, information, application andtechnology perspectives [8]. Fig. 1 depicts the EA put forward bythe Center of OrganizationalEngineering (CEO) [10] andrepresented with a UML class model.This conceptual framework combinestwo fundamental concepts; entitiesand roles in defining a conceptualframework to model the organizationin terms of organizational, business,information, application andtechnology views. Entities are thingsrequired for the enterpriseoperation. Entities may be concrete(e.g. people, machines) or abstract(e.g. an idea, a statement, anactivity definition). Roles definethe observable behavior of entities.Entities may play one or more roles.The CEO framework defines a set ofrole types that entities play withinthe enterprise. Figure 1 groupstogether the role types (classes)related to each view in a package.The organizational view comprisesmission, vision and goal, as well asorganizational unit roles. Thebusiness perspective synthesizes howbusiness strategy is implemented and

how processes are defined through thebusiness goal, process and activityroles. The information architecturedescribes what the organization needsto know to run its processes andoperations as described in thebusiness architecture. Morespecifically, it reveals informationof the actors, resources and state ofactivities. The last twoperspectives groups role types thatdescribe the IS/IT infrastructuresupporting business processes.EA Limitations. Current EA havestructures similar to the exampledepicted in figure 1. From thisconceptual structure of this figure,it is not possible to answerquestions such as: Which roles playsperson X? In which context(s)? How does Agent Xperform activity Y? How does Agent X interactwith Agent Y? How Agent X manages his differentroles, activities and resources?

Moreover, no answers are provided totime-related questions of givensubjects such as: At a given timeinterval t, Which role(s) are played by AgentX? In which context(s)? Which activity(ies)performs? Which resource(s) uses? With whichagents interacts? Which event(s) trigger Agent X’srole?

3

Figure 1. The CEO Framework

3. A model of OrganizationalAgents

In this section, we summarize thearchitecture and fundamental conceptsof this ontology proposed in [1]. Our framework is based on thefollowing concepts; activities, resources,agents, roles and contexts. Activitiesdescribe what organizations do andare identified with verbs. Activitiesare abstract entities that use andproduce resources and involve severalactions and interactions. Actionsdefine atomic acts performed bysingle agents that change the stateof some resource. Interactions arepairs of communicative actionsexchanged between two or more agents.Resources are the things relevant forthe operation of the organization andare identified with nouns (in ourmodel, entities are synonym oforganizational resources). Resourcescan be persons, machines, places, concepts orcapabilities. Agents are regarded asphysical and animate resources withspecial capabilities that enable themto (1) perform, coordinate and change

activities and (2) provide, consume,manage and change resources and (3)monitor, coordinate and change theirown activity and the activity ofother agents. Agents are identifiedwith nouns. Roles define theobservable behavior of an entity inthe scope of particular interactioncontexts [11]. Agents play severalroles and interact with other agentsthrough these roles. Roles aretemporal. Thus, agents performseveral activity or resource-relatedroles, at different times. Roles arealso linked to particular contexts.Contexts define situations thatemerge from successive interactionsamong resource and activity-relatedagents. Contexts group togetherinteractions and resources (activeand passive) related to one or moreactivities, at particular moments.Hence, time must be considered indefining contexts.

Fig. 3. Basic architecture andOntology

3.1 Agent Architectures

EA address organizational complexitydefining several, inter-relatedarchitectural perspectives. However,agents in EA are modeled only interms of their acting capabilities.This view does not acknowledge thecomplexity of individual agents. In

4

cognitive modeling, this complexityhas been addressed usingarchitectures as well. According toSloman [9], a typical cognitivearchitecture has the followingcomponents: (1) a perception box atthe left, (2) a (motor) action box atthe right, and (3) three internallayers connecting those two boxes.These internal layers are the reactivelayer, deliberative and reflective layers.Reactive mechanisms define agent pre-defined behavior. Deliberativemechanisms correspond to planning,scheduling and decision-making.Reflective mechanisms reflect agentabilities to change the behavior ofthe previous layers. In our work, weaddress both agent and organization’scomplexity through an integration ofagent and enterprise architectures.Current EA architectural perspectivescan be classified according two maindimensions; activities and resources.Thus, the organization as a whole ismodeled in terms of these twoperspectives. In turn, eachorganizational agent is modeled onthe basis of the three-layeredarchitecture described in [9].

3.2 Architecture of OrganizationalAgents

As a result, the fundamental conceptsdefined are used to model theorganization as a network of situatedinteractions between autonomousresource and activity-related agents.Figure 3 depicts the basicarchitecture of the model and relatedconcepts. 1. The Action Layer captures the

interaction patterns betweenactivity performers and resourceprovider or consumer agents.Interaction patterns are recurrent

flows of valid interaction typesand vary according to specificcontexts.

2. The Decision-making Layer capturesthe behavior of agents as resourcemanagers and activitycoordinators. As resourcemanagers, agents manage resources,including themselves. As activitycoordinators, agents coordinatetheir own activities andactivities of other agents. Thismeans capturing how agents reactupon according the state of theirinteractions i.e. theircommitments. Commitments trigger(activation) rules, which activategiven context (s), along withtheir associated activities andresources.

3. The Change/Learn Layer. This layercaptures changes in agent behavioras resource managers,producer/consumers, activitycoordinators or performers.(Interaction) rules governingthese changes are mostlyfrequently unobservable and tacit[3]. Hence, we do not aim atmodeling these rules. Rather, wefocus on detecting changes of theprevious layers.

4. The Human Perspective of EA

Figure 7 depicts the CEO framework EAincluding a human perspective basedon the model described in section 3.Adding a human perspective to EAentails first, distinguishing betweenindividual and collective subjects.Individual may belong to one or morecollective subjects (organizationalunits, teams, groups, etc.). Also, asingle individual handles severalpersonal contexts. From theperspective of the action layer,

5

within each personal context,subjects play different (private)roles and participate in differentinteraction contexts, playingdifferent (public) roles. Within eachcontext, subjects perform particulartypes of actions or interactions anduse a particular set of resources.Since subjects typically performactivities in different ways, actionsmay be related to differentactivities in different contexts.Hence, the relationship betweenactions and activities is context-dependent.

Figure 4. Human Perspective in CEOframework

From the perspective of the decision-making layer, contexts have anobservable state that allows thedepiction of time-based graphicsshowing when subjects activate theircontexts. This enables reasonableestimations of what subjects

(individual or collective) do atgiven moments i.e. which actions theyare performing and which resourcesthey are using. It also gives andidea of how individuals coordinatetheir own work and manage their ownresources along given time periods.From the perspective of thechange/learn layer, including time asan explicit variable allows detectinghow the work of individuals andgroups evolve in time. It is alsoregarded that each subject governscontexts according to personal rulesor cultural rules of the collectivesubject(s) to which the subjectbelongs. The inclusion of a humanperspective provoked changes in theCEO framework. First, the concept ofservice is no longer part of atechnological layer since humanagents can also provide them. Second,the cultural role was included in theorganizational view. The interactionrules included as part of thechange/learn layer belong to theorganization’s culture.

5. Examples from a Case Study

The basic architecture and ontologydepicted in figure 3 can be appliedat several levels of detail.Organizational agents and theircontexts of interaction can be usedin analyzing individuals, inter-personal relationships, groups andwhole organizations. Presently, itsapplication has addressed individualand inter-personal levels. At theselevels, the behavior oforganizational agents has beencaptured in a bottom-up fashion fromtheir actions and interactions. Thiswas tested in a case study where itwas collected over 650 actions andinteractions of a software

6

development team along a three-weekobservation period. The group wasintegrated by a team leader (Mariana)and 4 programmers (Alexandre, Carla,Gonçalo e Catarina). The team membersgrouped collected data in contexts.Several personal contexts wereidentified for each individual. Table1 illustrates some personal contextsof Alexandre, Carla and Mariana.

Table 1. Some Personal Contexts

The actions, action patterns andresources used by each individualvaried according these contexts. Forexample, the personal context m1 ofmariana is characterized by theaction types propose, assist, elaborate, print,update and discuss, and the resourcesteam meeting, project list, project plan, weeklyproject status report, information of on-goingprojects. Since contexts are situated intime, time-based representations ofactive contexts can be depicted.Figure 5 depicts Mariana’s activecontexts along the observationperiod. Analyzing each context allowsrelating them to specific activities.For example, the personal context m1of Mariana is related to theactivities, lead team meetings, elaborationof project-related reports.

m81 X X X X X X X X X Xm51 X Xm012 Xm011 X X Xm10 X X X Xm9 X X X Xm8 X X X X X X X X X X m7 Xm6 X X Xm5 X X X X X X X Xm4 X Xm3 X X X X X X X X X Xm2 X X X X Xm1 X X X X X X X X X

6 7 9 10 14 15 16 17 20 21 22 23 27 28 29 30

CONTEXTS

DAYS

Figure 5. Daily graph of activecontexts

This allows finding time-basedrepresentations of Mariana’sinteraction with tasks or activitiesalong several days (fig. 6).

lead team meetingsX X X Xellaborate project listX

update weekly status reportXperform integration testsX X X X X X X X X X

perform message maintenance X6 7 9 10 14 15 16 17 20 21 22 23 27 28 29 30

activities/tasks OBSERVATION DATE (month = december)

Figure 6. Daily graph of tasks

Analyzing contexts also allowstracing agent relationships withresources. Figure 7 depicts someresources of Mariana’s personalContexts. Italic-font resources (cardsapplication data, cards data) distinguishresources used in contexts notrelated to core tasks. Since theseresources are shared when people playsupporting or informal roles, theinteraction with these resources isnot captured when tasks or activitiesare modeled.

alexandre m1 m011antonio m1 m6 m012cards application maintenance m011cards data m011carla m1catarina m1 m2 m8cg team m3claims application m3 m4 m5 m51weekly status report m1

Resources Mariana's Personal Contexts

Figure 7. Context versus Resources

6. Conclusions and Future Work

In this work, we argue that thecommunicational power of EAframeworks can be used in depicting

7

graphical representations of theactual operation of enterprises.However, an extension andadjustment(s) to EA are required. Inorder to answer questions of theactual workings of enterprise, wepropose the inclusion of a human viewin EA frameworks. A human perspectiveallows capturing how subjectsestablish relationships withactivities, other subjects andtechnological resources. It alsoallows seeing the relationships ofgiven human agents with otherconcepts such as organizationalgoals. This kind of information isuseful not only for IS developers butalso, for organizational analysis andmanagers. Our proposal is based on aconceptual framework consistent withcontemporary organizational paradigmsand we illustrate with some examplesof a case study. The EA extensionrepresents a first step of ourresearch. Many more issues remain tobe addressed. The framework itselfrequires further development. Moreformal and detailed representationsmust be explored. Case studies thatwill provide further details onspecific uses of the proposedapproach are being conducted. Anotherissue to be addressed is exploringand testing ways of using IS/IT inbuilding and updating EA. Creatingand updating representations for thepersonal and inter-personal levelsentails analyzing high volumes offast-changing, frequentlyunstructured data. We are currentlyresearching semi-automatic mechanismsfor capturing, parsing and analyzingaction and interaction logs, as wellas personal and inter-personalcontexts.

7. References

[1] Zacarias M., Magahães R., CaetanoA., Tribolet J. Towards OrganizationalSelf-Awareness: An Initial Architectureand Ontology. In Ritten P. (Ed).Ontologies for Business Interactions. InPress[2] Orr K., Frameworks and Processes forDeveloping Enterprise Architectures,Enterprise Architecture 6 (2), retrievedJan-2006 from http://www.cutter.com[3] Giddens A., The Constitution ofSociety, University of California Press,1984[4] Tsoukas, H. (2005) ComplexKnowledge. Oxford: Oxford UniversityPress, 2005[5] Maturana, H.R. & Varela, F.J.Autopoiesis And Cognition: The Realization of TheLiving. Dordrecht, Holland: D. ReidelPublishing, 1980[6] Aldrich, H. E & Ruef, M. (2006).Organizations Evolving. London: Sage[7] Axelrod, R. & Cohen, M., HarnessingComplexity: Organizational Implications of a ScientificFrontier. New York, NY: Basic Books, 2000[8] Schekkerman, J. How To Survive In TheJungle of Enterprise Architecture Frameworks.Victoria, Canada: Trafford, 2004[9] Sloman, A. (2002) Architecture-BasedConceptions of Mind. In Gardenfors P.,Kijania-Placek K. & Wolenski J. (Eds.),Scope of Logic, Methodology, and Philosophy ofScience (Vol II), Synthese Library Vol.316 (pp. 403–427). Dordrecht: KluwerPublishers[10] Sousa, P.; Caetano, A.;Vasconcelos, A.; Pereira, C & Tribolet,J. (2006). Enterprise ArchitectureModelling with the Unified ModellingLanguage 2.0, in P. Ritten (Ed),Enterprise Modelling and Computing with UML.Hershey, PA: IRM Press[11] Caetano, A.; Zacarias, M.; Silva,A.R.; Tribolet, J., A Role-BasedFramework for Business Process Modeling.Proceedings of the 38th Hawaii InternationalConference on System Sciences HICSS Conference(HICSS’05), 2005.[12] Using Context for Supporting UsersEfficiently, Proceedings of the 36th

8

Hawaii International Conference onSystem Sciences (HICSS’03), 2003.

9