21
Reflec%ng on Enterprise Architecture as a Boundary Object for suppor%ng Change Prof. Balbir S. Barn Middlesex University [email protected] @balbirbarn 19/09/2013 1 20 November 2014, London
Reflec%ng on Enterprise Architecture as a Boundary Object for suppor%ng
Change Prof. Balbir S. Barn Middlesex University
@balbirbarn
19/09/2013 1 20 November 2014, London
Is Enterprise Architecture constrained by current Boundary
Object thinking?
An AlternaGve Title
“The difficulty lies, not in the new ideas, but in escaping from the old ones….” John Maynard Keynes, The General Theory of Employment, Interest and Money (13 December 1935)
Outline • Business – IT Alignment: the case for Enterprise Architecture
• The problem of measuring maturity of Enterprise Architecture pracGce
• The Boundary Object view of Enterprise Architecture • Binding Boundary Objects with Maturity Models: Lessons
• A new form of Boundary objects for EA • A PragmaGc Boundary – Value SensiGve Concerns • Concluding remarks
Business and IT Alignment: exisGng evidence
• Strategic Alignment DefiniGon: – The degree of fit and integra/on among business strategy, IT strategy, business infrastructure and IT infrastructure
– Strategic Alignment Model (SAM) (Henderson and Venkatraman 1993);
• Maturity Extensions along key dimensions (SAMM) by Lu^man (2004). – Governance, Skills, Architecture, Processes (12 in total).
• OrganizaGons that have aligned business and IT strategy will out perform those that have not. (Chan et al 2007)
19/09/2013 4
EA Role in Business-‐IT Alignment • EA definiGons are encouraging: • “An architecture is typically developed because key
people have concerns that need to be addressed by the business and IT systems within the organizaGon” – ARCHIMATE 1.0
• “it is a coherent whole of principles, methods, and models that are used in the design and realizaGon of an enterprise’s organizaGonal structure, business processes, informaGon systems and infrastructure” – (Lankhorst et al 2009)
• Enterprise Architecture plays a criGcal role in Alignment because it is a “boundary object” (Valorinta 2011)
19/09/2013 5
Valorinta, Mikko. "IT alignment and the boundaries of the IT funcGon." Journal of Informa/on Technology 26.1 (2011): 46-‐59.
Boundary Objects • TheoreGcal framework derives from social sciences
research (Star and Griesemer 1989) following a study of the Berkeley Zoo Museum.
• In their analysis of the arGfacts found in the zoo they idenGfied types of boundary object: – The repository – classified and indexed objects – Objects and Models – physical prototypes – Standardised forms – for facilitaGng communicaGon – Maps – idenGfying dependencies between objects and models and cross funcGonal problem solving
• Boundary objects help to cross various types of hurdles between different communiGes – Knowledge Boundaries: syntacGc, semanGc and pragmaGc
Star S.L., Griesemer J. (1989), „InsGtuGonnal ecology, ‘TranslaGons’ and Boundary objects: amateurs and professionals on Berkeley’s museum of vertrebate zoologie”, Social Studies of Science. 19(3), p. 387-‐420.
Boundary Object DefiniGon • Boundary objects are objects which are both plasGc enough to adapt to local needs and the constraints of the several parGes employing them, yet robust enough to maintain a common idenGty across sites. They are weakly structured in common use, and become strongly structured in individual site use. These objects may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translaGon.
Star S.L., Griesemer J. (1989), „InsGtuGonnal ecology, ‘TranslaGons’ and Boundary objects: amateurs and professionals on Berkeley’s museum of vertrebate zoologie”, Social Studies of Science. 19(3), p. 387-‐420.
CharacterisGcs of Boundary Objects
• Modularity: dealing with specific areas of a B.O • AbstracGon: common reference points of a B.O • Concreteness: applying a B.O to local use • AnnotaGon: enriching with addiGonal info. • Shared Syntax: A common schema • Accessibility: availability for different communiGes • Malleability: transformable for negoGaGon • Stability (versioning, up-‐to-‐dateness) • VisualisaGon: graphical or physical representaGon
Abraham, Ralf, "Enterprise Architecture ArGfacts As Boundary Objects -‐ A Framework Of ProperGes" (2013). ECIS 2013 Completed Research. Paper 120. hpp://aisel.aisnet.org/ecis2013_cr/120
Boundary Objects and Enterprise Architecture
• Modularity • AbstracGon • Concreteness • AnnotaGon • Shared Syntax • Accessibility • Malleability • Stability (versioning,
up-‐to-‐dateness) • VisualisaGon
TOGAF ArGfacts
Catalogs
Matrices
Diagrams
Archimate 2.1 Components
Meta Model Viewpoints
Diagrams
Boundary objects operate at the System 1 (Enterprise IT ArchitecGng (Lapalme 2012)
Malleability, the PragmaGc Knowledge Boundary and Enterprise Architecture
• Modularity • AbstracGon • Concreteness • AnnotaGon • Shared Syntax • Accessibility • Malleability • Stability (versioning,
up-‐to-‐dateness) • VisualizaGon
When communiGes of pracGce encounter pragmaGc boundaries, Malleability is essenGal. PragmaGc boundaries encroach on poliGcal and value-‐centric issues. In the case of the EA arGfacts this property is hard to implement because of its fixed form and staGc nature.
An AlternaGve Boundary Object for EA • Enterprise Architecture ArGfacts as Boundary Objects are
staGc and well-‐defined. • They don’t readily lend themselves to:
– provision of ease of comprehension of the “enGre” business – The play out of “what if” and “if what” scenarios
• I.E. Difficult to construct future theories of an Enterprise (Naur 1988).
• When this is is coupled with a need to address PragmaGc boundaries then the need for a boundary object that exhibits the property of malleability is important.
SimulaGon technologies (with caveats) presents an opportunity developing new forms of artefact that are malleable and support theory building of an enterprise.
EA as Boundary Objects • A general purpose of models is to answer quesGons about
the nature of the modeled enGty.
• When we do EA – it is o^en unclear as to what these quesGons are – hence we generate many and large models to miGgate risk (Ekstadt 2004)
The Viable Systems Model (Beer 1993) idenGfies decomposability and control variability as key ways of understanding an organisaGon. • EA models can do one but not the other. • Because of the Ashby Law: Controller must have more
variable states than the controllee.
Away from Boundary Objects: Major research quesGons include:
• What is the best mechanism for represenGng system dynamics in an enterprise architecture modeling tool?
• What constructs or arGfacts should be modeled in evaluaGng the dynamics of an enterprise architecture?
• Change induces stress in an architecture. • What is the measure of stress on the technical
infrastructure? – How do we measure and assess stress on the infrastructure? – How do we determine if specific changes will ‘break’ the architecture? – How does the architect use this measure (and others) to predict when
something will break as a result of changing the technical architecture?
Next GeneraGon Enterprise Modelling
“EA succeeds when enterprises are treated as complex systems that are constantly changing and adapGng.” Ken Griesi, in hpp://www.forbes.com/sites/jasonbloomberg/2014/07/11/
is-‐enterprise-‐architecture-‐completely-‐broken/ SimulaGon technologies (with caveats) can more easily represent complex systems.
Current Research CollaboraGon Language Engineering tools: MasterCra^ Modelling Research and ExperGse Access to Customer Problems
Language Engineering Tools: Xmodeler Enterprise Architecture SimulaGon Tools: LEAP Enterprise Architecture Research
Led by Vinay Kulkarni
Led by Tony Clark and Balbir Barn
Kulkarni, Vinay, Tony Clark, Souvik Barat, and Balbir Barn. "Model Based Enterprise SimulaGon and Analysis." In Advances in Conceptual Modeling, pp. 3-‐12. Springer InternaGonal Publishing, 2014 Balbir S. Barn, Tony Clark, and Vinay Kulkarni. Next generaGon enterprise modelling -‐ the role of organizaGonal theory and mulG-‐agent systems. In ICSOFT-‐EA Conference on So^ware Engineering and ApplicaGons 2014
Next GeneraGon Enterprise Modelling • The use of simulaGon tools to develop Enterprise Architecture ArGfacts.
• Grounded in: – Viable Systems Model – OrganizaGonal Theory – MulG-‐agent Systems
Environment OrganizaGon
Social Structure
Goals
ParGcipants
Technology
The Org. as Machine
Agents perform tasks in fixed structures comprising: -‐ Agent tasks; communicaGon paths and spaGo-‐temporal orderings Balbir S. Barn, Tony Clark, and Vinay Kulkarni. Next generaGon enterprise modelling -‐ the role of organizaGonal theory and mulG-‐agent
systems. In ICSOFT-‐EA 2014 -‐ Proceedings of the 9th InternaGonal Conference on So^ware Engineering and ApplicaGons, Vienna, Austria, 29-‐31 August, 2014 , pages 482–487, 2014.
Requirement for an Agile OrganisaGon
Goal
Goal Goal CXO
Business Manager
Engineer
simulate and analyze
simulate and analyze
simulate and analyze
Should be able to perform what-‐if analysis in order to make decisions at
all levels of the organizaGon.
EASE-‐Y ImplementaGon
Language Engineer
Meta-‐Language
Domain Specific Language
Kernel-‐Language
Domain Expert
Core Concepts
Kernel Engine
Kernel DSL Support
Stakeholder
High-‐level Common Concepts
Component, Interface, Message Goal, Plan, Therblig
Agent, State, Knowledge Group Dynamics, NegoGaGon
Low-‐level Implementa%on Concepts
Actor, Event, Concurrency FuncGons, Procedures, Data
Rules StochasGc Features
Enterprise Architecture and Value SensiGve Concerns at the PragmaGc Boundary
• Involving users in the design of systems has its roots in parGcipatory design
• Remains relaGvely neglected aspect in EA • Friedman (2006) is generally credited with introducing
value concepts into so^ware design processes • A value is “what a person or group of people consider
important in life” • Certain values are perGnent to EA
§ Ownership and property, Privacy § Freedom from bias, Universal usability, Trust, Autonomy § Informed consent, IdenGty.
§ Mobility demands raises stresses on EA • A key challenge is how to draw out value based concerns in
the EA processes. 19
Concluding Remarks • Enterprise Architecture has an important role in supporGng business and ICT alignment
• Languages to support EA such as Archimate do not readily lend themselves to construcGng a “whole” theory of EA for the organizaGons
• Archimate and TOGAF like frameworks are constrained by Boundary Objects that don’t exhibit properGes of malleability
• Research that supports theory building of an organizaGon requires some ability to simulate the execuGon of the organizaGon from goals through to system execuGons.
20
