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!

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.

News in the EA space

Following my last post, I decided to purchase three new books from Amazon:

• SAP Implementation Unleashed: A Business and Technical Roadmap to Deploying SAP;
• SAP: A Map of the Minefield; and
• Gary Hamel - What Matters Now: How to Win in a World of Relentless Change, Ferocious Competition, and Unstoppable Innovation.

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.

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. 

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.

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.”

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.