Showing posts with label enterprise architecture. Show all posts
Showing posts with label enterprise architecture. Show all posts

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

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