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.

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.