Friday, 16 November 2012

New Publication: A Systemic-Discursive Framework for Enterprise Architecture

John Gotze and I have published a new peer-reviewed paper in the Journal of Enterprise Architecture with the title: A Systemic-Discursive Framework for Enterprise Architecture. You can download the paper from here (note: this requires AEA membership). If you are not a member of AEA let me know and I will send you a PDF copy of the paper.

This article examines, through a case study of an Australian government agency, the systemic and discursive properties of Enterprise Architecture adoption in a government enterprise. Through the lens of Luhmann’s generalised systems theory of communication, the authors argue that the manner in which organisational communication is organised throughout the Enterprise Architecture adoption process has a noticeable impact on successful implementation. Two important conclusions are made: Firstly, successful Enterprise Architecture adoption demands sustainable resonance of Enterprise Architecture as a discourse communicated in the enterprise. Secondly, misunderstanding and reshaping Enterprise Architecture as a management discourse is an inherent premise for high quality adoption. The authors propose a new theoretical model, the Enterprise Communication Ecology, as a metaphor for the communicative processes that precede, constrain, and shape Enterprise Architecture implementations. As a result, Enterprise Architecture as a discipline must adopt a systemic-discursive framework in order to fully understand and improve the quality of Enterprise Architecture management programs.

Enjoy!

Saturday, 7 July 2012

Values of a good enterprise architect

What are the values of a good enterprise architect? Being in a consulting practice where I spend the most of my working life collaborating with CIO's, process owners, and senior architects, I often hear that question. Often the question emerges out of the usual debate whether a background in development and software engineering makes a better architect. Whilst there is no definitive answer to the latter question, I am quite convinced that first-hand experience with working in development teams and endless hours of coding, debugging, and troubleshooting source code is a big plus for aspiring architects - particularly because the architect will be the one bridging the gap between the business owners and the IT department. I know that because I have been there myself. And, in fact, I still enjoy developing software when I have time for it (for one of my latest pet projects, please see Fortune for Windows Phone, a port of the famous UNIX command /usr/bin/fortune for Windows Phone 7).

Now, back to the first question: what separates a top-shelf enterprise architect from the crowd of technical architects? In my opinion these values are:


  • Stakeholder management skills: being able to bring together business and IT people in order to resolve complex problems and agree on a future roadmap for the enterprise is a sought-after skill. A good architect understands how to engage and manage stakeholders in order to define a common foundation for improving the enterprise. 
  • Wide industry and consulting experience: architects are often hired as an internal "consulting" function in order to bring together and manage a vast array of different people, skills, and goals. Having consulting experience in combination with different verticals often puts things in perspective. And, as a plus, good consultants know how to navigate politically sensitive environments, which is a base requirement, particularly when navigating the wilderness of establishing an architecture governance function.
  • Leadership and trust: demonstrating leadership at the turbulent verge of technology fascination and the strive for business excellence is a rare skill. Enterprise architects understand and lead the translation of business concerns and turn these into tangible technology requirements and new business processes. However, this cannot happen without building trust across the board when transforming the organisation. Good architects develop trust  within the business by developing reusable solutions to their concerns. They show that architecture is the key management foundation for achieving business excellence. 
Knowledge of frameworks and methodologies is a plus. However, good architects can easily pick up any framework, thought process, or structured methodology and apply it in a meaningful way. Framework experience should not be your reason for hiring an architect. Good architects deliver value and business excellence with our without a framework. Rather, experience, common sense, and structured analytical thinking should be your main evaluation criteria.

Tuesday, 3 July 2012

News in the EA space

Following my last post, I decided to purchase three new books from Amazon:
I purchased the latter based on a previous recommendation from John Gotze. I still haven't come around to purchasing a Kindle or iPad yet so I am stuck with the good, old analogue book format. I prefer having books in my library anyway.
In other news, John has relaunched the EA Blog Aggregator under a new name - EAVoices.com. Very interesting mash-up move, which does a great job at aggregating the many good quality blogs on EA and enterprising out there.
Finally, John and I are publishing a new article in the Journal of Enterprise Architecture titled A Systemic-Discursive Framework for Enterprise Architecture. The article will be published in the August 2012 issue. I will put up the links here once it has been published.

Tuesday, 21 February 2012

Don’t buy flowers from ReadyFlowers

I usually don’t blog about my personal shopping experience, but a recent experience forced me to publish this post. I travel a lot for business, so for Valentine’s Day I decided to order a bouquet of flowers for my wife. Well knowing that online flower delivery is a trivial online commodity these days, I opened up Google and searched for “flower delivery”. One of the first hits was an allegedly Australian company, ReadyFlowers.com.au, which promoted their special same-day Valentine’s Day delivery of high quality roses. Order before 1pm and the flowers will be delivered the same day all over Australia, the company advertises proudly. Valentine’s Day is on February 14 and I put in my order for “6 long stem premium roses” (product link) on February 13 before lunch. According to ReadyFlowers, everything was all good and on track for delivery:



I was away for business on Valentine’s Day, so I ordered the flowers to be delivered to our apartment in the city as a surprise for my wife when she returned home after a long day at work. The flowers never arrived. I waited for her reaction throughout the day, but nothing happened. When I called her at night, I asked her: “So did the flowers arrive?” Puzzled and surprised she told me that she had not seen even a dry flower leaf at the doorstep.

Actually, the flowers did not arrive the next day – or the following day. On Friday February 17, I received a call from my concierge that somebody had dropped off a bouquet of flowers in the reception. When I got home, this is what I found:




They had sent my wife six small, dry roses without any water (normally, florists deliver flowers with a temporary water container so they remain fresh for the day). They were by no comparison the “six long stem roses” I had ordered. The flower heads were dry and mistreated. The wrapping was crushed. The obviously careless florist had added six dry leaves into the bouquet, most likely to compensate for the lack of fresh flowers and long stems. The greeting card, for which I was asked to add a friendly note during online order, was crushed. My wife’s name was not spelled correctly.

Unsurprisingly, I was furious. Not only had the company decided to charge me AUD $ 90.90 (almost DKK 500) for this pathetic so-called “bouquet” of dry, mistreated roses. They also delivered them three days too late without sending me a single notification of delay. Even half-decent companies send a quick apology and an estimated time of delivery to their clients if orders are stuck or delayed. But ReadyFlowers? Zip, nil, zero, nothing. As I was waiting for the flowers to arrive, I called ReadyFlowers’ so-called customer service centre three times (a 1 800 number) with no luck. Both times I was stuck in the waiting queue as number 23 or 33 with “an estimated holding time of 65 minutes”. Go figure. At least I knew that I was not alone in my pointless endeavour to trace up my missing flower delivery. The third time I called, I was in the queue for 20 minutes before I was diverted to a voice mail with the friendly message that ReadyFlowers had taken their customer service  offline due to a high number of calls! I What kind of company pulls the plug on their customer support during expected peak periods?

Friday, I called the company on the Friday the flowers had arrived. Instead of going into the “enquire about existing orders” I selected the third option for local distributors. This time I got straight through to a ReadyFlowers employee within two minutes. I explained my story and complaint to the customer “service” officer (named Leo) who obviously couldn’t care less about their recent atrocity. I explained to him that I expected them to come and pick up the flowers and that I wanted an immediate refund. Leo, who was probably working in a call centre far away from Sydney, responded that his managers had “left work for today” without any kind of apology or desire to help me. He asked me to send them an email with pictures of the flowers (which I did) and they would get back to me as soon as possible. This, of course, turned out to be a pure scam -- five days have gone by without a single reply from the ReadyFlowers service desk. I have sent multiple requests to their support email address – still with no reply.

I can’t emphasise this enough: ReadyFlowers is a scam, a fraudulent company that should be penalised by the ACCC. They simply to not deliver what they promise on their web site and they overcharge their clients for products that do not meet the expected, decent level of quality and timeliness. Save yourself time and money – avoid ReadyFlowers at all costs.

My next step is taking this case to the ACCC, NSW Fair Trading, and, if necessary, the NSW police. 

Tuesday, 10 January 2012

Communication Architecture

In my previous research, I have investigated the relationship between transformation, planning, and communication in large-scale architecture programs. Obviously and unsurprisingly, communication has a huge impact on the perception and relative success of enterprise architecture and change management initiatives. The important turning point, that I have argued so far, is the way communication shapes and is shaped by the organisational systems in which it takes place. The German sociologists Dirk Baecker and Niklas Luhmann have been my primary sources of inspiration and research for formulating a set of guiding principles for change programs that do not simply assume that communication is a fully informed and unambiguous process of sending and receiving objectified information. Organisations and their people are all systems in which communication takes place. The boundaries, values, and cognitive processes of each system influence and complicate the practice of communication, which, in turn, requires a complex systems model to model and explain its behaviour.
Most architecture methodologies highlight the need to share and communicate architectural plans and roadmaps with key stakeholders in a timely fashion. Whilst frameworks often offer templates and tools, they often fail to explain how and why stakeholders may not understand or simply ignore the intent and agenda of enterprise architecture. Technical problems, overtly detailed artefacts, and too abstract abstractions are often mentioned as the reoccurring problems when attempting to “sell” enterprise architecture to the CXO level. Paradoxically, what was meant to help, guide, and transform the enterprise has now become its own architectural swan song as it drowns in a bureaucracy of templates, procedures, and formalities. This is an indication that the intent and purpose of architecture was not communicated properly to the right people at the right time.



Architectural layers and principles ensure that enterprise transformation is carried out in a coherent fashion. The prime role of the architect is to balance and align business and technology and link these factors back to the enterprise’s objectives, mission, and vision. However, despite communication having a huge impact on people, change, and actual outcomes, it has never been an explicit part of this equation. Communication is often assumed to be rational and presumed to be well-functioning, running in the background of people’s minds and the organisation’s offices just as the Java garbage collector picks up and purges empty object pointers in the Java virtual machine. Assuming a highly complex, volatile social process to behave in such an ordered, rational manner is all too simplistic: human communication and social processes simply don’t behave that way.

So what is the alternative? The obvious choice is to integrate communication as a core concept and layer in enterprise architecture itself – the communication architecture. Here, communication refers mainly to the social processes of human and computer interaction and – not pure computer networks or algorithmic manipulation of signals. On the other hand, communication is not only about people and utterances – computers and technology play a vital role as well as an efficient transport medium. My point is that communication in itself is a socio-technical system describing the complex message exchange between humans, intentions, and machines – or, in C. S. Peirce’s words, a semiotic system. Semiotic systems have dissipative structures of signs in networks constituted equally by humans and machines. Communication in enterprises can be interpreted as complex signs, manifested in dialogues, written emails, and network packets in the router. Some communications are relatively stable (a published document or a sequence of bytes representing an email) whereas others are fragile and chaotic (human intentions, political agendas, gossip by the water cooler).  Their manifestations are entirely different, but the purpose remains the same: exchanging ideas, values, and intentions – utterances – between people in- and outside the enterprise in order to ensure its long-term survival. As I havepreviously pointed out in this blog, enterprises as socio-communicative systems have rhizomatic properties – the modern enterprise should not be solely viewed as a hierarchy of processes, layers, and computers, but also as a constantly transforming multiplicity of events and signs. Thus, the theoretical foundation for describing the communication architecture of the modern enterprise must be found within the theory of organisational semiotics and sign theory.



In upcoming blog posts I will attempt to tie these very theoretical reflections back into a practicable architecture framework for organisational communication.

Wednesday, 21 December 2011

Common Pitfalls of Solution Architecture Governance

Framework-ism: Form and structure over content and good practice (not best practice). Best practice is all too often a cover for theoretically ideal, but practically non-functional solutions.
Boil-the-ocean-ism: All too generic frameworks intended for large-scale program transformation lack local focus and technical guidance.
Architecture astronaut-ism: Abstraction upon abstraction upon abstraction until everything is so conceptual that end-users have dissolved into TOGAF deliverables.

My mantra for solution architecture governance is:

“In IT governance land, it is OK (read: critical!) to be IT- and solution-centric. After all, it is called solution architecture, not conceptual framework theory.”

Sunday, 11 December 2011

IBM's Open Source Enterprise Generation Language

I recently discovered that IBM have released their Enterprise Generation Language (EGL) toolkit as open source in a donation to the Eclipse project. That is definitely a nice move by IBM who are already one of the core contributors to both the Eclipse development platform and the Linux kernel.

So what is EGL? Wikipedia describes EGL as follows:

"EGL is a high level, modern business oriented programming language, designed by IBM to be platform independent. EGL is similar in syntax to other common languages so it can be learned by application developers with similar previous programming background. EGL application development abstractions shield programmers from the technical interfaces of systems and middleware allowing them to focus on building business functionality. EGL applications and services are written, tested and debugged at the EGL source level, and once they are satisfactorily functionally tested they can be compiled into COBOL, Java, or JavaScript code."


Prior to IBM's release I had never heard of EGL. It seems to have been hidden in their myriad of Rational legacy tools including the VisualAge enterprise tools for code generation and model-driven architecture (MDA). Apparently, it is quite an abstract language, which compiles into a set of different target platforms including Java, COBOL, and Javascript, depending on the solution architecture. Technical middleware and deployment are "hidden" from the developer so that he/she can concentrate on getting the business logic right as opposed to defining the technical configuration. 


Now, what does this remind me of? Sun's (and now Oracle's!) Java EE and the Enterprise Java Beans (EJB) platform. Java EE (previously J2EE) was the call for an open platform specification, which sought to solve deployment and configuration for developers and free up time for modelling requirements and implementing business logic. Transactions, persistence, and scalability were "built in" to the platform. Unfortunately the first versions of the EJB specifications were so horribly complex (remember EJB 2.x?) that developers spent an increasing amount of time on understanding persistence mechanisms, transaction handling, and writing XML files for relatively trivial tasks. Only with version 3.0 did EJB become "human" and demonstrated its full power as a relatively simple, fully mature application platform. That is not to say that EJB was not mature before -- it was just horribly complex. The higher the degree of embedded complexity, the higher is the chance of unintended errors. I know this because I have developed EJB v2 and v3 applications myself. I honestly hope that EGL does not suffer from the same legacy problems as EJB and that it can be integrated with more "lightweight" approaches to application configuration such as convention over configuration, Don't Repeat Yourself (DRY), and fluid interfaces.


EGL is a refreshing toolkit for the open source enterprise community. Even though I now spend my working life as an architect (and no longer as a software engineer), I still follow the enterprise software landscape closely. I have just downloaded the EGL Eclipse package from the web site and will follow up with some comments here in my blog.

Wednesday, 7 December 2011

Clever Spam

A couple of days ago some random spammer sent me the following e-mail:


It actually looks exactly like the e-mail notifications I receive daily from Twitter -- that is, except for the link content. Apparently they were not clever enough to mask the content of the underlying link with a random URL shortener. :) This e-mail was actually caught by Gmail's spam filter. I must say that I am impressed by the speed and intelligence of their spam detection system. It is very rare that it actually catches ham.

The Modesty of Writing

Blogging, e-books, and social networks have all increased the speed at which we communicate—or, from a Luhmannian perspective, how we share our utterances with the communication. For DIY publishers, the Internet is an infinitely rich channel for publishing their own content and making it available to readers and consumers at exactly the same premises as previously professional channels. And that is awesome: the Internet has democratised the way we make available and publish our thought and ideas. Recently, I have become involved in a book on cybernetics and enterprise architecture. The book was initially thought to be available through a DIY publisher and furthermore freely available as an e-book. However, due to increasing interest from traditional publisher, the book will now be published through a traditional publication channel. To me, both opportunities are equally exciting.
However, the rapid speed of immediate “publication” comes at the cost of lack of modesty, patience, and maturity. Some people use blogs to quickly fabricate and churn out trivial variations on the same topic over and over and flood the public sphere with their own opinions in a synthetic, insubstantial manner. Proof-reading is completely unheard of; proper referencing to prior art and information sources is considered almost arcane. Blogging is supposed to be a quick, responsive medium. However, when people post entire book chapters or even book manuscripts through the same source and under the same preconditions, the form and shape of blogging have certainly moved in the wrong direction. The fundamental problem is that people with blogs tend to lack the modesty of traditional writers, academics, and publishers. For blogging “pracademics”, this is furthermore caused by the lack of patience for peer-reviewed publications. Preparing a good paper can take months before it is accepted and published. For the average blogger with lots of intentions, it is, of course, a lot easier to churn out one blog post after another with incoherent fragments of argumentation and structure. If post-modernism had a place in the history of literary shapes and forms, blogging would certainly be its most significant incarnation.
Writers, researchers, and bloggers alike must return to the tradition of when pages were sparse and publication a controlled, rigorous process requiring discipline and modesty. Only through modesty have the most purposeful, unique utterances, be they peer-reviewed publications or news items, been created.

Thursday, 15 September 2011

New Publication in Journal of Enterprise Architecture

My research paper on systems thinking, sense-making, and enterprise architecture planning in government has been published in the Journal of Enterprise Architecture, a quarterly, peer-reviewed journal published by the Association of Open Group Enterprise Architects (AOGEA). The paper includes a case study of architecture-enabled transformation of a government agency merger in NSW, which includes geospatial location awareness, service oriented architecture, and enterprise integration. The paper is titled: Processes of Sense-Making and Systems Thinking in Government Enterprise Architecture Planning.

My abstract is as follows:


This purpose of this article is to investigate the systemic properties of Enterprise Architecture Planning (EAP) in the Australian government sector. Based on a case study of the Land and Property Management Authority of New South Wales, the article examines and outlines the crucial necessity for including systems thinking, systems learning, and organizational sense-making in Enterprise Architecture (EA) theory and planning. The main argument is based on qualitative research into the limitations of capturing and modeling organizations using EA methodologies and modeling approaches.
The EA discipline, including its tools and methodologies, relies on the metaphor of engineering the enterprise and building stable taxonomies of knowledge and process. The practical reality that e-government programs are facing is technical, sociological, and messy. However, EA tends to operate within an engineering metaphor that assumes stability, predictability, and control. Here, the author highlights the necessity of an alternative, less positivist approach to EA planning in order to understand and articulate the tacit knowledge dimensions and messy, wicked problems of organizational life.
Soft systems thinking, socio-technical theory, and sense-making are introduced as theoretical and practical frames to overcome these limitations and produce a better, more viable and realistic model of planning in government enterprises. These concepts are finally amalgamated into a general, integrative model of EA planning.

You can download the paper from here (AOGEA membership is required).

Tuesday, 26 July 2011

Towards Next Generation Process Execution

A considerable part of my professional time is spent on advising people on discovering, redesigning, and --- if possible and feasible --- automating their business processes. Often, trivial, cumbersome, and predictable processes can be formalised and executed using a process engine (also known as BPMS, Business Process Management Suites). Process execution is usually combined with an enterprise service bus (ESB) or middleware layer, which supplies data sources and exposes business transactions to the process layer in an open, reusable, and interoperable fashion.
BPMS is by no means a new concept. Most contemporary BPMS platforms began as workflow engines and CASE (Computer-Aided Software Engineering) tools, which subsequently found valuable use in the rising Java EE and enterprise application integration (EAI) markets of the 90’s and onwards. This, combined with an increasing interest in information management and enterprise integration, spawned today’s plethora of repository based modelling tools, sophisticated middleware technology, and process execution platforms.  
Looking into the crystal ball of process automation, what automation technologies can enterprises expect to see in the years to come? Now, here, any average IT analyst would probably come up with three all-too-often-adopted shrinkwrapped concepts:
  1. Cloud computing
  2. X-as-a-service
  3. Agile
In order to actually coming up with something original or different, I have deliberately omitted these three words in this blog entry. That is not to say that these trends aren’t influential or important, but they have already been stated elsewhere in thousands of blog posts, whitepapers, and academic papers. In the following sections I will present my stance towards aspects of next generation process automation.

Closed-Loop Roundtrip Engineering
Several toolchains support the so-called ‘roundtrip’ between repository-based enterprise modelling tools and implementation level process development tools. Too often this is a one-way exercise in which business processes are modelled by the business analyst, approved by the process owner and then exported to execution by the solution architect. However, once the process model hits the implementation floor, governance, roundtrip, and traceability are cut off. The process model is now materialised as source code rather than a visual model.
An improved, closed-loop roundtrip approach would most likely solve this bridge by making the process integration point both ways. This calls for an improved bridging strategy between the two worlds so they ultimately merge into one. That is not to say that the designed process model must equal the executable process model --- the enterprise repository should still provide different, role-based views onto the same processes. The tipping point that I am arguing is that full traceability from model to execution demands to-way traceability and unified single-interface version control of all artefacts.

Light-weight Executable Process Models
Modelling standards such as BPMN 2.0 (Business Process Modelling Notation) claim to provide single, uniform language for modelling manual, semi-automated, and fully automated business processes. However, as several process practitioners have already emphasised, the notation is still far too rich and complex for non-technical professionals and businesspeople to fully comprehend. It is as if the notation, indulging in its own ambitions and adoption, has widened its gap too far and suddenly struggles to articulate all possible aspect of a process.
SOA practitioners struggled with the same complexity problems in the early 2000’s. Everywhere, new and half-baked service standards emerged, and some “standards” even offered duplicate functionality. For SOAP, what was meant to be a simple protocol for exchanging messages had now morphed into a wilderness of WS-* standards, policy documents, and pseudo recommendations. As a counter effect, REST (Representational State Transfer) was adopted as a viable, lightweight, and easy-to-implement alternative to the WS-* conglomerate. REST’s elegance was its simplicity, very similar to how the simplicity of the TCP and IP network protocols defeated complex, proprietary network protocols such as DECNET and Tymnet. Useful, open standards are easy to simple and easy to understand and communicate. WS-* was by no means a lightweight stack, just as BPMN 2.0 is too rich to be truly elegant.
What BPMS needs is a process modelling notation that is just as elegant as REST and TCP. The simpler notation, the easier it is for business analysts to pick up the notation and understand a particular model. Fewer moving parts and modelling exceptions also implies that the designed process is easier to execute. Consider the source code necessary for parsing a WSDL schema with surrounding WS-Security artefacts compared to lines of code necessary to retrieve and parse a JSON data structure across a TLS-encrypted wire. For execution, a light-weight process model format with different role-based process architecture views are necessary accommodate for easy-to-communicate and easy-to-execute processes models. 

Process Variations
My third idea is the notion of modelling and execution of process variants. Several enterprise modelling tools (such as ARIS) support the idea of variant artefacts, which allows for a configuration item to be traced back to its reference artefact. This is particularly useful when mapping a process model or architectural layer against a set of reference architectures, which in turn allows for quick discovery and gap analysis of compliance requirements.
However, for some reason this idea has yet not made its way to process execution land. The majority of BPMS platforms treat process models as isolated, transactional entities. References are done by related events or drilling into sub process models. Process layering and variation are completely unknown concepts in the world of execution, despite its inherent adoption in enterprise modelling. Many enterprises struggle with the need for selecting and executing a particular process variant depending on a set of pre-conditions, whilst still being able to reflect that the instance belongs to a particular group of variants. An executable billing process might vary slightly depending on the type of the client currently being billed, but the process is still the billing process. Integrating process variations in BPMS theory adds depth and context to the executable process models, as opposed to pure, isolated workflows.

Process Regulation and Self-Reference 
The research field of control theory and cybernetics has for long explored the properties of self-organising systems, which respond in a meaningful way to outside stimuli. Examples of cybernetic systems are everything from simple thermometers to complex jet fighter engines, which monitor and regulate their current state depending on the environment (such as temperature or altitude). Similarly, researchers in business process management (BPM) and process engineering have explored the idea of self-regulating processes: business processes that monitor, adjust, and control their own state, activity, and performance based on the general condition of the overall enterprise. In manufacturing this would be a process, which adjusts its production throughput automatically based on recent market trends received from the business intelligence system. Sales processes adjust their current inventory data based on market forecasts triggered by an external supplier. Car manufacturing robots do just-in-time adjustment of assembly line activity after observing a major slump in the stock market five minutes ago. The modern enterprise is event-driven, interconnected, and immediately responsive. However, in order for business processes to exploit this opportunity they need to become self-regulating or “self-aware.” Executable processes must be able to adjust their own complex states based on listeners and triggers from external events. This technology demands sophisticated complex event processing and a meta-process environment, which allows for easy and dynamic reconfiguration of process model layout, design, and performance based on external data. The change in state should not be limited to a pre-configured set of process patterns. Process models and metadata should automatically infer new possible process designs and subsequently select the most plausible design based on previous design choices, feedback, and execution data. 

To Be Continued
These considerations are only a small part of the ideas I have been collecting for next generation process automation, which could very well evolve into a general research programme on the future of BPMS. It is my opinion that we have reached a solid state of enterprise integration tools and middleware platforms. However, BPMS theory and practice is still in a state of flux: shiny new tools emerge every day, but fact is that we have very little experience with designing, deploying, and maintaining complex, large-scale process applications. Granted the general principles of software engineering and IS development theory still apply: effectively, most process applications involve enterprise systems in the large with a vast amount of moving parts and integration points. However, in order to successfully respond to the increasingly rapid markets and requirements change, we need faster, simpler, context-aware, and interconnected BPMS platforms driven by self-regulation and complex event processing. In my upcoming blog posts I will write more on this topic.




Announcing Upcoming Book: Systems Thinking in Enterprise Architecture

Dr. John Gøtze and I have announced the forthcoming publication of a new book titled: Systems Thinking in Enterprise Architecture. The book, which targets the intersection of practitioners and academics, explores the important, notional relationship between Enterprise Architecture (EA), systems thinking, and cybernetics. A wide array of authors have been invited to contribute to the book resulting in a total of 20 chapters on the topic. 

Systems Thinking in Enterprise Architecture is still the working title of the book and it expected to change once all chapters have been reconciled. The book will be published in the Systems Thinking and Systems Engineering Series by College Publications, thus marking the successor to the remarkable volume 1: A Journey Through the Systems Landscape by Harold "Bud" Lawson, who is also one of the joint contributors to our book.

In order to read more about the book, please refer to the ITU Enterprise web site for deadlines, list of contributors, and publication guidelines. If you are interested in contributing, please do not hesitate to send us a draft manuscript!

Saturday, 9 April 2011

Rhizome: On Dilemmas in Enterprise Architecture Planning


In the field of IS and management we often put forward a certain conception of the organisation, the social. In contemporary business consulting and management academia, the organisation is often conceptualised as a hierarchical open system with a certain body of knowledge supplying the management system with rational decision making. Other alternative, academic approaches are influenced by literature studies and Gadamer’s hermeneutics (Gadamer, 1975), promoting the need for understanding and context, the particular, rather than the universal and manageable. Emerging from these two spectra, each fighting for their own conception of subjectivity and objectivity, Anglo-Saxon and continental philosophy, each defining the criteria for truth and meaning, one uncovers systems theory and cybernetics which proposes a model for generalising structures and properties between different phenomena in the world: Bertalanffy (Bertalanffy, 1969) suggests a unified cybernetic model for living, mechanic, and social systems, whereas von Foerster (Von Foerster, 2003) and Luhmann (Luhmann, 1995) suggest a second order model based on constructed observation and interpretation. In organisation studies, first and second order systems theory each postulate their own conception or construction of social reality: Parsons defines the social as actions or events referring to each other within a structural organising of social functions, whereas Luhmann flips the tin can with a functional organisation of social structures based on communication, reproducing and sustaining itself through Maturana and Varela’s concept of autopoiesis (Maturana & Varela, 1980).


Amidst IS management’s--and thus EA’s–attempt to establish a common, trans-disciplinary foundation for research, there appears to be an ontological schism of what the social is and organisations really are. Is it a collective intelligence or logic of rational decision making? Is it a reactive, intersubjective collective attempting to make sense of the world in hindsight through history and culture? Or is it a system or a construction of a system that organises, structures, or communicates through constant adaption and recursive reproduction only by reference to its own recursion and reproductivity? The latter approach dissolves the former two boundaries by creating a boundary of distinction even more important than the understanding subject itself at the edge of every possible system. It is the distinction between system and environment that generates or fabricates meaning and truth, but it comes at the cost of reducing our very own processes of cognition and sensemaking to a set of vibrating antennas or satellites mounted at the fragile surface of every human system.  

An ontology of the social is thus far from complete. Enterprise Architecture (EA) seeks to address this by building layers of abstraction and control, thereby assuming that static systems models of socio-technical relations yield manageability and transparency. Accountability is achieved by linking formal role descriptions to process models and system landscapes, often positioned in a well-defined hierarchy and stored in a database repository for later reference and reuse. In order to reuse ‘best practices’ and assure a certain level of maturity in framework and methodology, enterprises often implement their architecture practice against existing reference frameworks and enterprise meta models. Frameworks such as FEAF even include a CMMI-like maturity model for EA, which assesses the success of architecture program by measures such as completeness and integration. OMB, the US Federal Office of Management and Budget, has furthermore published a set of measures of architectural completeness for evaluating US Federal Agencies. The highest achievement, level 5, is the architectural utopia in which the organisation practicing EA corrects its own business failures by architectural inspection. Architecture is here synonymous with optimising an organisation.

Given the above reflections on what the social really is, is it really philosophically reasonable to suggest that a stable, decomposable, hierarchical model, which most enterprise meta-models really are, is capable of building a comprehensive model of the social? Is it really meaningful to stretch virtually any organisation, be it government or private, along a five-level diagram and measure it by how well-described architectural elements are? And what happens when the Federal agency hits the ceiling after 5? Those are clever and important questions that information and organisation science ought to ask. Unfortunately, that is seldom the case. Maturity models, in the classic form of a five-step ladder, are an inherent part of any contemporary management/IS theory: process maturity, architecture maturity, service maturity, integration maturity. The five-step Capability Maturity Model (Paulk, 1995) has its roots in systems engineering carried out by engineers building space shuttles for NASA. As universal as it may be, the problems, issues, and solutions faced by modern organisations are far more muddy, messy, an ill-defined than those originally faced by defence contractors and DoD bureaucrats. Such fast-paced, deep problems are also characterised as wicked problems (Rittel & Webber, 1973):
  1. Wicked problems have no definitive formulation. One can infer that the problem exists, but will never be able to fully document the problem.
  2. The solution to a wicked problem is “good or bad” not “true or false”.
  3. Every possible solution is a one-shut operation as every solution attempt will leave a trace which cannot be undone.
  4. Each wicked problem is unique and may eventually be the symptom of another, underlying wicked problem.
Through my previous research, I have suggested a systems theoretical approach towards understanding and explaining EA. Systems theory is helpful towards describing the messy complexity of social and communicative structures. Second order systems theory adds a rich, dynamic theory for understanding communication in- and outside organisation by describing the exchange of utterances between human actors in search of meaning (Jensen, 2010). I believe, however, that these two key conceptions of enterprise planning and governance can furthermore be extended into a general theory of EA by including Deleuze's theory of the rhizome.


Deleuze (Deleuze & Guattari, 1988) describes the rhizome structure (Deleuze & Guattari, 1976) as a meaningful alternative to uncovering complex structures, be they social or biological. Western society, Deleuze explains, has built its historicity and philosophy on the basis of binary structures: true-false, yes-no, top-bottom, maturity-immaturity. Contemporary EA frameworks are, in fact, highly binary: layers separated by clear boundaries, processes with a start and end, structured organisation charts and capability maps with a top and bottom. The rhizome is a viable alternative since it assumes an inherent complexity of what it is intended to describe. The rhizome is constantly transforming and morphing itself, making it virtually impossible to map out its structure completely at any point in time. This is exactly how wicked problems occur. Wicked, messy problems could, in fact, be described as rhizomatic structures. The rhizome structure applies well to the socio-technical nature of organisations as well, as the dissipative relationships between humans, technology, and organisation structures form a complex, dynamic, and transforming entity with no clear, formal, or necessarily logical order. This rhizomatic relationship is probably best explained in the field of technology adoption and diffusion in private enterprises where traditional positivist approaches to management and innovation struggle to explain how and why technology trends emerge and behave. This reflection on Deleuze leads to the following important claim:

Organisations are complex, dissipative structures constantly transforming complex, human knowledge and social relationships. A rhizomatic systems model satisfies such conception of organisational reality. Hence, Enterprise Architecture, in its search for whole-of-enterprise views, should adopt rhizomatic theory for uncovering and understanding the true messiness of organisations as socio-political habitats.

Understanding Enterprise Architecture as a rhizomatic systems practice, however, must come at the cost of killing certain darlings. The first darling is the idea of organisations as stable structures operating on explicit, verifiable knowledge, which in turn can be divided into clear architectural layers and segments. The second darling is the conception of a universal maturity model explaining the natural progression towards “EA nirvana”. There is no such one.
  1. Layers, segments, and hierarchical models depart from a Westernised, binary view of the world. Layering suggests decomposability and abstraction of organisational complexity. A rhizome does not have such properties. The messy, social facets of organisational life cannot be decomposed or functionally abstracted. The social does not have a single function and thus cannot be functional. Wicked problems, as they emerge from social interactions and organisational problems, are rhizomatic and cannot be explained fully through rationalist models.
  2. Maturity models are inherently binary. They suggest a natural progression towards the optimal stage 5 somewhat similar to a tree as it stretches its branches towards the rising sun. The rhizome is the exact opposite of a tree structure as its roots and shoots grow and form in any direction, shrouding and shifting its original structure. Social structures, apart from the general statistical patterns uncovered by social psychology, do not follow universal laws of transformation or branching---and hence it is impossible and meaningless to suggest a generic, universalistic maturity model of social behaviour in EA adoption and planning. There is no such nirvana of Enterprise Architecture---and if there ever were, it would be constantly shifting and transforming depending on the current managerial climate, problems of planning, and struggle for control inside the organisation. Exactly this relationship of management, planning, and control is rhizomatic as well.

For Enterprise Architecture to fully explain these sacrifices, it must adopt a view of the enterprise as a non-linear, interconnected multiplicity, for which structures can only be meaningfully traced and described in hindsight. Traces always remain interpretations. Enterprise modelling involves tracing organisation structures, but as these structures are traced and interpreted, they suddenly shift and transform into a different multiplicity. Enterprise Architecture is thus a semiotic practice of tracing and interpreting organisations as complex signs. The output, the long-term plans, roadmaps, and meta-models, are merely simplified pictures of these dissipative signs. Only by accepting these aspects of enterprise reality, can Enterprise Architecture truly characterise the challenges and solutions in strategic planning and enterprise management.  

References:
Bertalanffy, L. v. (1969). General System Theory; Foundations, Development, Applications. New York,: G. Braziller.
Deleuze, G., & Guattari, F. (1976). Rhizome : Introduction. Paris: Éditions de Minuit.
Deleuze, G., & Guattari, F. (1988). A Thousand Plateaus : Capitalism and Schizophrenia. London: Athlone Press.
Gadamer, H.-G. (1975). Truth and method. London: Sheed & Ward.
Jensen, A. O. (2010) Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation. Copenhagen Business School.
Luhmann, N. (1995). Social Systems. Stanford, Calif.: Stanford University Press.
Maturana, H. R., & Varela, F. J. (1980). Autopoiesis and Cognition : the Realization of the Living. Dordrecht, Holland ; Boston: D. Reidel Pub. Co.
Paulk, M. C. (1995). The Capability Maturity Model : Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley Pub. Co.
Rittel, H. & Webber, M. (1973), `Dilemmas in a General Theory of Planning', Policy Sciences 4.
Von Foerster, H. (2003). Understanding Understanding : Essays on Cybernetics and Cognition. New York: Springer.




Thursday, 7 April 2011

On the Brink of Structure and Chaos: Framework Prescription and Real-World Flexibility

An often returning discussion with my clients is the practical applicability, boundaries, and presumptions of enterprise architecture (EA) frameworks. Following a recent debate on LinkedIn, some EA practitioners suggest that dynamic systems models, such as Stafford Beer’s Viable Systems Model (VSM) (Beer, 1994) , should actually replace existing prescriptive framework practices. In my own thesis (Jensen, 2010), I furthermore discuss the options of integrating cybernetic and second order systemic models in enterprise architecture planning and management on the basis of a thorough analysis of Australian government EA and SOA practice.
However, in this debate, it is important not to frame systems thinking as the silver bullet, which can magically and immediately fix all problems of management practice, be it process management or government architecture planning. Systemic thinking in itself may, actually, be overly prescriptive through reductionist assertions of how organisations function, e.g. through the claim: “organisations are systems” as opposed to “organisations behave as systems in particular situations.” Assuming that the world consists of systems as an ontological pre-given only paves the way for yet another prescriptive theory.
I usually tell my clients that there are two key observations around healthy framework and methodology practice. This basically boils down to admitting the following two claims:
  1. Best practice frameworks and reference models provide a great starting point and rational structure for beginning an architecture endeavour. Obviously, you don’t need to reinvent the wheel, and the frameworks provide a common language and conceptual platform for sharing ideas and implementing projects. Any good framework provides the tools, templates, and management structure for relatively quickly deploying the skeleton of an architecture practice. Prescription gives guidance, direction, and shared understanding of EA purpose and planning.
  2. However, prescription may also heavily limit the creativity and flexibility of rapid transformation projects. EA is often put in place in order to rapidly change the organisation for the better --- or what Hjort-Madsen (2008) calls architecting for better outcomes. If the method is too inflexible or does not allow people to make shortcuts and rapid improvements for the better, it is a sign of too heavy prescription. Architecture turns into a handicap as opposed to providing a viable management reporting function. Architecture has transformed into a heavy-weight documentation exercise producing massive stacks of documents that nobody will ever return to again.


Good framework practice comes from finding the right balance between structure and flexibility. The framework must guide, direct, and support the architects at work so they can share and reuse where possible. On the other hand, the framework should promote and highlight the appropriate degree of managerial buffer in order to easily overcome problems and churn out creative solutions as opposed to locking down framework users by applying layers of managerial review and approval bureaucracy for the sake of (often unnecessary) traceability. As my thesis research indicates, an Australian state government agency chose to temporarily ignore their EA modelling and documentation framework whilst transitioning from current to future state.  Technological, political, and managerial changes occurred so often that the existing reference framework was simply too prescriptive. After reaching a point of reasonable stability in terms of business requirements and change in demand, it was then feasible to return to the structural stability and rigour of the framework.
My key message is therefore: be careful when implementing your architecture practice in your organisation. Your people need structure and guidance but also flexibility and buffer for overcoming changes rapidly in an elegant fashion.

Beer, S. (1994). Brain of the Firm (Classic Beer Series). Wiley.
Hjort-Madsen, K. (2009), Architecting Government: Understanding Enterprise Architecture
Adoption in the Public Sector, Phd doctorate.

Friday, 18 February 2011

Quality Criteria for BPMS Programs

Recently, I have been initiating a Business Process Management System (BPMS) implementation for a major client in the financial sector. This made me wonder: how can I come up with a set of BPMS-specific, practical quality criteria for successfully implementing a flexible, repetitive, and fast BPMS platform? However, some people are not aware of the important distinction between BPM (Business Process Management) as a management philosophy discipline and BPMS as an enterprise IT program:
  • BPM is defined as the overall management philosophy, which frames the enterprise as consisting of a set of end-to-end business processes. These processes, in combination, deliver value to the organisation's clients. Improving the enterprise means architecting, improving, and managing these processes for better outcomes. 
  • BPMS is a collection of software tools and systems engineering practices based on process management thinking. BPMS realises the modelling, automation, execution, and monitoring of business processes on a common, single-instance runtime platform, often through the use of open, well-defined service contracts (such as web services). 
Some vendors equate workflow tools to BPMS, which is not necessarily the case. An enterprise BPMS often involves implementing a workflow. However, the key notion is that modelling and executing business transactions as processes yields predictability and transparency. 

My work has inspired me to pursue writing a pracademic paper on common quality criteria and heuristics for enterprise BPMS implementations, particularly concerning roles, values, expected outcomes, actual outcomes, pitfalls, and general performance improvements. What worked and why? What didn't work out as expected? What business criteria should the CIO and solution architect focus on when planning or building the business case for BPMS? How did can one ensure a higher quality BPMS? 
Granted, several IT governance frameworks already provide generic measures and KPI's. What I am interested in is the process- and IS-specific criteria and measures relating directly to BPMS programs.

Thursday, 27 January 2011

Architectural Control as a Managerial Paradox

In recent years, IS academia has argued that EA is increasingly becoming a strategic management tool or a high-level business function for long term planning and execution. It has been a healthy evolution for EA to question its IT heritage and adopt a broader perspective of how commercial enterprises navigate and gravitate in their respective marketplaces. This healthy evolution has particularly been articulated by Turner, Gotze, and Bernus (2010) in their paper Architecting the Firm: Coherency and Consistency in Managing the Enterprise, which argues the key role of architecture in executive management. Architected organisations are said to achieve better, more consistent results since the strategy is aligned and architected against operations, processes, and the technology portfolio.

As I have previously argued in my writings on strategic management, the assumed reality of strategic long term planning has to a large extent ignored the socio-political side of human and organisational behaviour. Planning is volatile and subject to rapid change in turbulent environments. As Rittel & Webber (1973) argue in their 1973 article on government policy and planning, assuming that any problem can be solved by rational planning will ultimately lead to confusion and failure. In their view, assumed rationality leads to unexpected ambiguity. Here, it is crucial to ask the question: if EA really is such a strategic discipline driven by the need for informed decision making, how can the first and always at-the-top-of-the-framework-pyramid component called strategy rely on such a naïve view of how human planning works in practice? This discussion is by no means new; already in the late 90ies, Mintzberg (2002) argued the need for an organic, emergent view of strategy by elaborating on Simon’s (1997) concept of bounded, contextual rationality. 

Let us for a short moment forget about strategy as an applied, deliberate package of human reason and rather think of strategy as inherently equivocal. Management concepts, as they often arrive straight out of the business scholar’s first year text book on business strategy, are, in fact, paradoxical and ambiguous despite the strive for precision and forecasting. This is explained in the following:

  1. The first paradox concerns the relationship between assumption of control vs. human and environmental ambiguity. The more one attempts to control and superimpose predictability onto reality, the more imprecise and irregular reality, in fact, becomes. This classic paradox of the manager as an assumed homo oeconomicus is discussed in depth by Kallinikos (2004).
  2. The second paradox is three-sided: the short, very generic nature of corporate vision and mission statements vs. the corporate search for control and manageability vs. the complexity of the business ecology surrounding the enterprise. The first facet is short and simple, where the second facet strives for precision, detail, and consistency, both which in turn neglect the ecological complexity and institutional pressure (the third facet) of the organisation’s environment.
  3. The third, most noticeable paradox is the fact that the implicit equivoque of high-level mission/vision statements fosters organisational resilience. The more loosely or ill-defined the strategy, the better will the official policy document fit into the actions and immediate strategies (what Weick (2001) denotes just in time strategies) deployed by employees to fulfil or achieve certain goals and expectations (Astley & Zammuto, 1992). The more ambiguous the official strategy or policy articulation, the more free hands for the individual employee to appropriately navigate the socio-political problems of the business environment. Despite the intended precision of a strategy document, the more possible interpretations of a strategic policy or plan, the more organisational resilience and responsiveness (Weick, 2001).


However, it is too simplistic to assume that corporate ambiguity per se triggers organisational resilience and flexibility. In that case, any old plan would do.The paradoxical nature of precision and ambiguity is better understood as a second order systems theoretical concept (Luhmann, 1995 & Luhmann, 2000), in which any system, be it social or biological/ecological, applies certain reductionisms in order to reduce the outside complexity the environment. In Luhmann’s theory of symbolically generalised media within social systems, phenomena such as scientific truth, politics, sex, and power are applied by different institutional systems in order to reduce the complexity and ambiguity of modern society. Similarly, organisations as social systems deliberately deploy equivocal mission statements and simplistic strategies in order to interpret and cope with a hyper-complex, fast-paced business environment. Despite the claim of predictability, strategic long term plans are thus put in place in order to reduce societal complexity and constraints to static architectural maps and prescriptive policies. The reduced conception of reality is by no means successful or comprehensive enough to account for all important details simultaneously, but it makes reality manageable until the actions taken and plans made are reasonable enough (see  reasonableness as a criterion for strategic success in (Weick, 2001)). 

As Teubner (2000) writes, strategic planning fosters productive misunderstandings: business strategies have to be misunderstood (compared to what was originally intended by e.g. senior management) and reinterpreted in the particular reality and bounded rationality of the individual. The final, synthesised (mis-)understanding of strategy, mission, and vision serves to build and sustain resilience and organisational responsiveness---but only with reference to the organisation itself. As Luhmann’s sociology tells us, the end result would never achieve the same results in the outside reality. This also explains why replicating or adopting existing patterns of strategy will most likely lead to a bad result without adopting, contextualising, and productively misunderstanding the presumed strategic rationality. Good strategies are misunderstood, self-referential and contextual whilst fostering resilience and adaptability.

It is my conception that EA must adopt such view of strategic thinking as a self-referential, ambiguity-producing human practice in order to successfully navigate the needs and requirements of tomorrow’ adaptive and flexible virtual enterprises.

References
Astley, W. G. & Zammuto, R. F. (1992), `Organization Science, Managers, and Language Games', Organization Science 3(4), 443{460.
Kallinikos, J. (2004), `Deconstructing Information Packages: Organizational and Behavioural Implications of ERP Systems', Information Technology & People 17(1), 8-30.
Luhmann, N. (1995), Social Systems, Writing Science, Stanford University Press, Stanford, California.
Luhmann, N. (2000), The Reality of the Mass Media, Stanford University Press, Stanford, California.
Mintzberg, H., Ahlstrand, B., & Lampel, J. (2002). Strategy safari (2nd ed.). LT Prentice Hall. 
Rittel, H. & Webber, M. (1973), `Dilemmas in a General Theory of Planning', Policy Sciences 4.
Simon, H. A. (1997), Models of Bounded Rationality, Massachusetts Institute of Technology, MA.
Teubner, G. (2000), `Contracting worlds: Invoking discourse rights in private governance regimes', Social and Legal Studies 9, 399-417.,
Turner, P., Gøtze, J., Bernus, P. (2010) Architecting the Firm: Coherency and Consistency in Managing the Enterprise. In Bernus et al (2010) Enterprise Architecture, Integration and Interoperability: IFIP TC 5 International Conference, EAI2N 2010, Held as Part of WCC 2010, Brisbane, Australia, September 20-23, 2010, Proceedings. 
Weick, K. E. (2001), Making Sense of the Organization, Blackwell Publishing.

Sunday, 23 January 2011

Bank Branches need Process Improvement

I am generally a happy client with my personal bank here in Australia. Their online services are good, they have excellent phone service, always reply to my enquiries with a smile, and service fees are kept at a minimum. However, two weeks ago I had an experience I thought belonged to the pre-Gorbachev era. My wife and I went to the bank in order to integrate consolidate our bank accounts and personal finances. Also, we wanted to migrate a single credit card into both our names as shared card holders. With many couples consolidating their banking business every day, this really shouldn't be a complex process, even though it turned out to be a dull three hour experience. Forget about going to the bank in your lunch break to finally get those accounts sorted out: you will need at least an afternoon to get things right.
Let's investigate the processes involved in this relatively client request: 
  1. Verify client identity
  2. Open x new client bank accounts
  3. Transfer funds from existing bank accounts to new bank accounts
  4. Close y old client bank accounts
  5. Update client and card holder details for MasterCard credit card
  6. Verify details and finalise client request
For a bank (and the branch officer), these processes should be relatively trivial and simple. Following Porter and Harmon (Harmon, 2007), these are core bank service processes. I had expected 30-45 minutes including a couple of signatures, a few mouse clicks, and maybe an internal phone call to a service desk. How could that result in three hours? These were the main process flaws:
  1. The poor customer service officer spent more time looking for the correct paper forms and subsequently printing these out for further processing. The bank has a comprehensive Intranet site providing access to all client request forms with an enormous tree folder structure, and she even tipped over the screen so I could have a look for the right place to find the form. All relevant forms for a account closure and account opening were located in completely different folders, completely detached from the actual client task. Furthermore, all forms were given long, cryptic names, which made the whole operation even more painful (who would have guessed that HD30 is the code for an account transfer request?).
  2. Lack of task and process orientation: the user interface on the service officer's screen was data-driven and not process-focused. For each step in the processes, she had to navigate through a hierarchy of different Intranet pages to find the right forms and data entry screens. Some of these screens (or web based wizards) were task oriented, but only at the most local level. One client request thus consisted of invoking six different wizards dispersed over three different application systems each with its own user interface, constraints, and terminology. I would recommend looking in to consolidating end-to-end business processes inside the same process engine operating on the same account data.
  3. Basic process tasks were delayed and not properly formalised. It is crucial for a bank to verify the identity of its clients to prevent fraud, also for people walking in from the street. Verifying the client's identity should this be a basic condition for proceeding with any further steps in the above processes. But only after 30 minutes spent on printing out five-six different request forms and allocating all of our bank accounts did the service officer actually ask for our driver's licenses in order to confirm that I was actually me. Now, what if I had forgotten my driver's license and I had to come by another day? That could have saved both her and I for 60 wasted minutes, although I fortunately had remembered my license. It is probably the most basic conditional task (or in BPMN terms: decision gateway) for all basic client processes. All requests demand confirming the correct identity. Move all conditional, security and identity related decision points to the earliest possible point in your banking process. It might sound like common sense, but with multiple entry points for invoking a client request (online, in person, phone call), it is crucial to use integrate all authentication in a uniform fashion across all business processes.
  4. No visual graphic of process path and progress---neither for the service officer or client. A visual progress overview generally makes people more patient and clarifies the tasks at hand (imagine having a non-technical EPC or BPMN model of all of the above processes for the customer service officer to follow).
  5. No process Key Performance Indicators or client feedback integrated into the workflow. The friendly, but frustrated customer service officer could have ended the (albeit very lengthy) transfer process by asking me: how would you rate this transaction? Is there anything we can do better? Process improvement demands learning and systems feedback being fed back into the next process cycles. Only from incremental improvement cycles can significant process improvements be won (Seddon & Caulkin, 2007). This demands a balance between quantitative (e.g. processing time, number of mouse clicks, processing/systems exceptions) and qualitative process indicators (client satisfaction, that friendly smile on the face, welcoming clients in the branch, offering them a glass of water whilst the banking transaction is cooking) (Zokaei et al., 2010).
These recommendations and conclusions are by no means revolutionary or unique. The important difference is that ideas emerged from a---at least in the blueprints---simple visit to my local bank; a visit that in the end brought a lot of frustrations and ultimately improvement ideas on the table. With the billions of dollars each year spent on IT portfolio management and business analysis in the financial sector and a GFC finally returning to the historical wastelands of our capitalist society, one would assume that significant improvements---and (systems) learning---have been discovered. Paradoxically enough, the budgets are apparently still spent on building cluttered unintuitive user interfaces and manually integrating disparate data sources at the cost of redundancy, whilst ignoring the fundamental structure of systems learning and feedback.

References
Harmon, P. (2007), Busines Process Change, 2nd edn, Morgan Kaufmann Publishers.
Seddon, J. & Caulkin, S. (2007), `Systems thinking, lean production and action learning', Action Learning: Research and Practice 4(1), 9-24.
Zokaei, K., Elias, S., O'Donovan, B., Samuel, D., Evans, B. & Goodfellow, J. (2010), Lean and Systems Thinking in the Public Sector in Wales (Report for the Wales Audit Office), Technical report, Lean Enterprise Research Centre, Cardi Business School, Cardi , Wales, UK

Wednesday, 29 December 2010

Update: End of Thesis, New Book

This blog has been dead for a while, partially due to a major, positive change of circumstances in my private and professional life. First of all, I married my wife on September 25 in Sydney. Hence, my surname has changed to Jensen-Waud. I will use this on all blog entries, e-mails, and social networks---including LinkedIn---from now on.
Secondly, I finished my master's thesis with the final (catchy) title: Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation (click here to download a PDF format from Google Docs). I was awarded full marks (ECTS cale: A, Danish scale: 12, Australian scale: HD) for the final product with the a remark of excellence from my supervisor, Dr. Gotze: apparently it has excellent potential to evolve in to a full-scale PhD thesis. I will examine my options and possibilities in the near future for turning this in to a full-scale PhD or doctorate in business administration
My next project is to work on a book with the Sourcing Initiative with the headline: Enabling Collaboration. The time frame of the book is 12 months with  updates released publicly on an incremental basis. The book is a not-for-profit project with the final product being released under the Creative Commons license, very similar to the loosely knit network of authors contributing to Dr. Gotze's popular and important book on e-government and government 2.0.
So what will the agenda of my contributions be? The theoretical foundation of the book is that Enterprise Architecture is an important instrument for managing organisational sourcing processes. Given the recent interest of describing and architecting business and operating models for building and shaping the modern enterprise---particularly when shed in the theoretical light of the virtual organisation (Raffaini 2001)---I have formed my own research area of interest. When sourcing business operations and enabling collaboration in the extended enterprise, it is crucial to understand how each enterprise relates to others, especially in terms of regulations, knowledge production, profit generation, collaboration, and communication. In the classic, Zachman-inspired view of the enterprise (Zachman 1987), an enterprise architecture provides a static, consistent snapshot of an (extended) enterprise at a certain point in time. Building several architectural representations of all the enterprises sourcing and collaborating in the extended enterprise is thus key to managing efficient and effective sourcing processes. However, as I stated in my master's thesis, the enterprise is too complex to build a uniquely transparent and consistent picture at any point in time. Instead, I argue, it is the core role of Enterprise Architecture to highlight the communicational and discursive processes taking place within and in between the virtual enterprises. 
A second, important research factor is that the analysis and management of sourcing processes should depart from and emphasise systems thinking as a means for understanding how social and communicative entities in the extended enterprise cooperate, constrain, and collaborate with each other. 
Sourcing enabled by Enterprise Architecture thus carries two important dimensions: 
  1. A systemic dimension describing how the virtual network of enterprises emerges and is managed in a coherent fashion through architectural thinking
  2. A communicative (discursive) dimension describing how the flow of information and knowledge in the sourcing value chain should be captured and understood in a holistic manner.
The final theoretical foundation is built on K. E. Weick's theory of sensemaking (Weick 2001) and Luhmann's general theory of social systems (Luhmann 1995, Luhmann 2000).

For now, have a very Merry Christmas and a Happy New Year wherever in the world you may be.

References
Luhmann, N. (1995), Social Systems, Writing Science, Stanford University Press, Stanford, California.
Luhmann, N. (2000), The Reality of the Mass Media, Stanford University Press, Stanford, California.
Raffaini, M. (2001). The Virtual Organisation, in Proceedings of the 7th International Conference on Concurrent Enterprising, Bremen.
Weick, K. E. (2001), Making Sense of the Organization, Blackwell Publishing.
Zachman, J. (1987), `A Framework for Information Systems Architecture', IBM Systems Journal 26(3), 276-292.

Sunday, 18 July 2010

Case Study Mode

Hello Fellow Followers, 
I am sorry for the radio silence, but I have been extremely busy writing up my case studies for the last month. It is the biggest and most important part of my thesis. Luckily, I have been provided to really interesting case studies from two Australian state government agencies: Ipswich City Council in QLD and Land and Property Management Authority in NSW. 

Both case studies focus on the adoption of EA and meta-modelling practice within a government context. The results have been very interesting, and I honestly can't wait to publish my findings. 

Meanwhile, hang on. I am still here, and there are some interesting writings to be released!

Cheers

Anders

Tuesday, 8 June 2010

On Government Adoption of Enterprise Architecture as an Institutional Process

 During the past few days, I have been reviewing Kristian Hjort-Madsen's PhD 'Architecting Government: Understanding Enterprise Architecture Adoption in the Public Sector' in relation to enterprise ontology and enterprise modeling methodologies. A vast amount of his referenced research publications is framed around institutional theory, in which organisations are seen as acting in various institutional fields (e.g. professionalism, legislations, polices, technological trends) that stimulate and constrain organisational decisions (Dimaggio & Powell, 1983). Hjort-Madsen believes that this is one of the key influences behind EA adoption [1], but it also comes at the cost of theoretical lopsidedness with a paradoxical backlash: institutional forces might explain certain reasons for EA adoptions in government, but institutional analysis tends to ignore the importance of free will of agency and rather draw its explanations from abstract, nearly autonomic forces in the organisational environment. Ultimately, the importance of free will—both on the individual level and within organisations—is trapped inside an institutional iron cage manifested in socially contrived institutions that—paraxodically enough—were created, maintained, and bureaucratized by human free will in the first place. Several researchers have criticised the institutional approach:
  1. Hasselbladh and Kallinikos frame the popularity of institutional analysis in organisation theory whilst acknowledging its analytical tendency to reify social, emergent structural forces: “[...] the social and cultural processes that make up the project of rationalization and shape the structure functioning of work organisations have either been bypassed or given an exogenous status, reified to ’reality’, ’society’ or ’environment’ and treated as independent variables in cross-sectional or longitudinal empirical research.” (Hasselbladh & Kallinikos, 2000, p. 698) Neo-institutionalism, the authors say, grew out of a organisation studies as a response to classic positivist thinking: “[Neo-institutionalism emphasises that] Organizations are not responses that eolve as detached rational calculations. [...] The realist-materialist conception of organizations as adapting systems in natural environments of resources, threats and opportunities has, thus, again been brought to the fore and criticized as inadequate, on several grounds.” (Hasselbladh & Kallinikos, 2000, p. 698) This shift might get rid of some problematic assumptions, but the result is merely another reduc- tionistic approach: organisational rationality now happens “by reference to legitimacy, as the major prerequisite for organizational survival and success.” (Hasselbladh & Kallinikos, 2000, p. 699)—but praising legitimacy as the key variable in organisational logic is merely shifting the influencing parameter in the same first order systemic view of organisations [2].
  2. Another key problem with institutionalism is tendency towards generalisability and the perceived birds-eye view of the organisational field, which tends to neglect local actions: “Neo-institutionalism offers no account of the means through which a domain of action is conceived, rules of conduct, performance principles and devices of controls are developed and forms of actorhood constituted.” (Hasselbladh & Kallinikos, 2000, p. 701) The global, generalising institutional perspective thus takes precedence over local meaning production, whilst failing to account for how and why a specific process of institutionalisation emerges and exerts influence (Hasselbladh & Kallinikos, 2000, p. 702).
  3. Mintzberg extends the above problems into management and strategy (Mintzberg et al., 2002, ch. 10), where he clearly explains the problems of institutional theory: organisations are turned into fruit flies swerving wildly in a thick, hazy porridge of policies, regulations, and cultural norms. Individual, strategic decisions (e.g. government adoption of ITIL) is turned into a programmatic stroke of the environment, invisibly but collectively manuscripting the behaviour of every CIO. After all, as Mintzberg writes, “what is an ’industry environment’ but all the organizations functioning in it?” (Mintzberg et al., 2002, p. 297)—or is the environment merely a social construction that actorhood applies locally in order to cover up for mistakes or irrational behaviour? Mintzberg rightfully labels this view “looking at the world through the wrong end of a telescope” (Mintzberg et al., 2002, p. 293), and this is exactly what Hjort-Madsen tends to practice when he backtraces government practice to an illusorily forceful environment.
In summary, selecting an institutional foundation for analysing EA programs might provide a more qualitative framing of EA, but it is still: 
  1. reductionistic in the sense that organisational behaviour and rationality are mainly shaped by external institutional processes reified into a certain corporate reality. Rather, these processes are created and sustained by social, contrived entities (e.g. bureaucracies)—and not prescribed through scientific laws of society.
  2. ontologically paradoxical, since an institutional understand pays more attention to the so- called environment than the organisations inhibiting the environment, but fact is that the environment is constituted by nothing but the inhibiting organisations in the first place.
  3. ontologically imbalanced since it removes the analytical focus from local, immediate and particular to a birds-eye view in search of generalisability.
It follows from these conclusions that institutional theory is -- on its own -- insufficient for describing and explaining the complex social mechanics of government adoptions of EA -- or any other transdisciplinary methodology with a high degree of organisational volatility and complexity.

I will work on how to developing and extending these views. Feel free to comment as I am looking for counterpoints and additional material and research material for inclusion in my thesis.


Footnotes
[1] For instance, see (Hjort-Madsen, 2007) (Publication II in (Hjort-Madsen, 2009)), (Hjort-Madsen & Marjin, 2007) (Publication III in (Hjort-Madsen, 2009)), (Hjort-Madsen, 2007) (Publication IV in (Hjort-Madsen, 2009)), and (Hjort-Madsen, 2009, p. 18, 20, 36, 61).
[2] As Hasselbladh and Kallinikos assert, Parsons’ structural functionalist framework for sociology already high- lighted the importance of inter-subjective meaning and interpretation in 1951 (Trevino, 2001). Thus, some aspects of institutional theory are very close to Parsons’ systems theory of society—and therefore not an inherently new theory of paradigm for understanding social organisation.

Sources

Dimaggio, P. J., & Powell, W. W. (1983). The iron cage revisited: Institutional isomorphism and collective rationality in organizartional fields. American Sociological Review, 48, 147-160.
Hasselbladh, H., & Kallinikos, J. (2000). The project of rationalization: A critique and reap- praisal of neo-institutionalism in organization studies. Organization Studies, 21(4), 697- 720.
Hjort-Madsen, K. (2007). Institutional patterns of enterprise architecture adoption in govern- ment. Transforming Government: People, Process, and Policy, 1(4), 333-349.
Hjort-Madsen, K. (2009). Architecting government: Understanding enterprise architecture adop- tion in the public sector. Phd doctorate.
Hjort-Madsen, K., & Marjin, J. (2007). Analyzing enterprise architecture in natinal governments: the cases of denmark and the netherlands. In Proceedings of the 40th hawaii international conference on systems sciences. Big Island, Hawaii.
Mintzberg, H., Ahlstrand, B., & Lampel, J. (2002). Strategy safari (2nd ed.). LT Prentice Hall. Trevino, A. J. (2001). Talcott parsons today: His theory and legacy in contemporary sociology.
New York: Rowan and Littlefield.