Requisite-fuzziness

How should we respond to inherent-uncertainty in qualitative-requirements, for enterprise-architecture and the like? Yes, we can reduce every qualitative-requirement to some sort of metric, but is that always a wise thing to do? And if not, how can we tell whether

The Project Business Model SWOT

This post is the sixth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with. […]

An Overview of Mobility and BYOD Technology

This is the fifteenth post in my series on BYOD. I have mostly avoided talking about technology, as in many ways that is the least important, and the most straightforward aspect of dealing with BYOD. Most people automatically think of Mobile Device Management (MDM) when they think of mobile or BYOD technology, but that is far from […]

Has in-person communication become the unwilling victim of technology?

In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change.  In other words, it is great to have the data to point to a problem in an enterprise.  It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc).  Change requires more than simple communication.  It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.

Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication.  That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing.  Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.

I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes.  I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.

As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation. 

Enterprise Architecture is more difficult because of this shift in communication patterns.  All forms of face-to-face communication are hampered by it.

Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.

This worries me.

AGILE architecture vs. agile ARCHITECTURE

As an architect involved in an agile implementation (my current gig), you can imagine how interested I was to see that there’s a new book on Agile Architecture, and perhaps how disappointed I was to see that it focused on SOA and Cloud.  That’s not to put down SOA or the cloud.  I’m a huge fan of both.  But it wasn’t the area of agility that I was hoping that a book, with that title, would address.  The misunderstanding was mine, not the authors.  I haven’t read the book yet, but I’m sure I will.

That moment of misunderstanding crystallized a thought: how even a two word phrase like “agile architecture” had two completely different meanings.  The opening scene of the movie “The Hobbit, An Unexpected Journey,” puts a rather humorous twist on this idea, when Gandalf introduces himself to Bilbo Baggins (who has apparently forgotten having met him as a boy).

Bilbo: Good Morning

Gandalf: What do you mean? Do you wish me a good morning, or mean that it is a good morning whether I want it or not;

Bilbo: <stunned silence>

Gandalf: Or that you feel good this morning; or that it is a morning to be good on?

Bilbo: All of them at once, I suppose.

Of course, in Enterprise Architecture, we have the same problem.  Does Enterprise Architecture mean “the practice of using technology architecture at an enterprise-wide scale,” or does it mean “the practice of using architectural ideas to shape the enterprise itself?” 

And after a bit of stunned silence, perhaps it means

“Creating an architecture to describe the externalities of an enterprise to set its context and improve the relationships it has with customers, partners, and suppliers?” 

All of them at once, I suppose.

Having just re-watched the Hobbit movie on my morning flight, these bits connected up in my head.

I’m proud to be both an architect of agility (applying the principles of agility to the processes of a business so that the business achieves the ability to change its own processes in response to agile demands), as well as a person who can craft technology architecture that reflects the notion of agility itself (technology that can be set up to change rapidly in response to business events).

All of them at once, I suppose.