Updates from September, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • muraterder 9:23 pm on September 29, 2014 Permalink | Reply  

    Collaboration and Communication – 50% of the Work 

    Ivory tower is a label quite often applied to architects within an enterprise. They can be seen as people that draw pretty diagrams and add no value. The overall objective is to make architects become part of the organization and not perceived as a separate entity.

    Trying to extract value from architects can result in quite interesting scenarios. At one point, an enterprise decided that all architects needed to be formally part of a central organization. This was to ensure that all architects were trained and applied a consistent approach, but was really more  a “power play” by a senior manager.

    About six months after this change, the senior manager realized he had a group of a couple of hundred people and was getting challenged by his management about the value his architects provided. To make sure that he could justify the group, he decreed that every architect had to charge their time to actual projects. This resulted in a scenario where anyone in IT who launched a project suddenly found a queue of 5-6 architects knocking on their door – from the data architect to the network architect. Obviously this did not do so well in increasing the trust of the architecture function.

    Most architects focus their effort in ‘building’ the architecture. This is natural since normally fairly technical people that enjoy building systems become architects. However, ‘socializing’ the architecture is equally (if not more) important.  In summary: Improving the perception of the architecture function is 50% of an architect’s job and requires soft skills.

    What do real architects do?

    The recent decades have seen an increase in the concept of the ‘celebrity’ architect. They are successful due to their ability to sell an expensive vision, fund it but also have the ability to execute. If you look at the opening page of Gehry Partners website (http://www.foga.com/) you see the following quote:

    Gehry Partners employs a large number of senior architects who have extensive experience in the technical development of building systems and construction documents, and who are highly qualified in the management of complex projects.

    The most interesting part about the above extract is the emphasis on management of complex projects – normally not seen as a core competency of IT architects, maybe it should be?


    The Dancing House by Frank Gehry and Vlado Milunic in Prague.

    There is no easy cook-book on how to improve communication around the architecture function. However, focus on the following communication tools would be a good starting point:

    1. Vision and Storyboard: This is stating the obvious – you have to know what your product is before you can try to market it. It is important for an architecture function to clearly identify how it is adding value to the enterprise. This is usually done at the senior management level via a set of PowerPoint presentations. Though we do agree that a vision and mission statement for architecture is required; once it is articulated, the value of the architecture should be self-evident.
    2. Communication Channels: The architecture function in an enterprise has to communicate with all sets of stakeholders. This goes from the CxO level – who has to be convinced of the value of the architecture to the DBA who is trying to figure out if they should use stored procedures. Creating channels for open and bi-directional communication with the different stakeholder groups is required to reach out to such a wide variety of interests.
    3. Artifacts and Tools: One of our favorite definitions of architecture is: “ A bag of tools and the wisdom to know when to use them”. Crystallizing and packaging architecture artefacts and tools so that they can be easily digested and used by different stakeholders is another key success factor. The most important principle here is self-service. In other words, the artefacts and tools should not require from the reader to have a PhD to understand them.
    4. Process: At the end of the day the architecture activities live within a process within the enterprise. It is important to understand the impact on SDLC and change management.
    5. Financials: Ability to articulate value in financial terms is a holy grail in terms of architecture. This can become an all consuming task it taken to the nth degree of detail. However, a level of financial awareness is a must. 

    As can be seen from the above points, focusing on the collaboration and communication aspects of architecture is not an effort that is left as an afterhours exercise. It should be taken seriously and any architecture function in a large enterprise should have dedicated roles focusing on these aspects.

    The table below provides a simple overview of how the communication tools can be applied to different stakeholder groups. It has been color coded where green represents most relevant, amber somewhat relevant and grey not relevant at all.


    As can be seen different tools and techniques are required to address different stakeholder groups. It should be noted that the only tool that is highly relevant for all stakeholder groups is the establishment of the correct communication channels.

    • Jeff Ryan 9:36 pm on September 29, 2014 Permalink | Reply

      Nice post. I lived through a scenario similar to the one outlined where architects were brought into a central organization and had to learn how to show value to stakeholders. I was surprised not see business partners listed as a stakeholders architecture must gain alignment and support with, particularly, since architects scope and frame efforts from business / technical perspectives, and need to have credibility with the business. Showing value to business partners can accelerate acceptance by other IT roles…


      • muraterder 7:17 pm on September 30, 2014 Permalink | Reply

        Hi Jeff,

        Very good comment on business partners. You are totally right that they are a very critical stakeholder. The table was focused on a sample set and looks like I have fallen into the IT trap of focusing internally more than externally; just what I was trying to avoid.

        From one perspective business users seem to understand architecture better – they naively assume that IT should be acting in a structured manner. However, if you try to play the business case/financial benefit angle they can be very critical.


  • muraterder 8:29 pm on September 17, 2014 Permalink | Reply
    Tags: , , , ,   

    Architects Unit of Work – Architectural Decisions 

    If you ask most people what is the most visible output from architecture, they will most likely point to a fancy diagram that highlights the key components and their interactions. Usually the more color and complexity the better. Ideally it should be too difficult to read on a normal page and requires a special large-scale printer to produce. Though such diagrams give the authors and readers the false sense of being in control – they normally have no impact on driving any architectural change.

    The most important output of any architectural activity is the set of decisions made along the product development journey. It comes as a surprise that so little effort is spent on arriving at and documenting architectural decisions in a consistent and understandable manner.

    Most architectural decisions have the following elements:

    • Problem Statement: State the problem are we addressing and the context.
    • Motivation: Explain why we need to make  the decision at this point in time.
    • Constraints: It is important to clearly articulate all constraints related to a decision – architecture is in essence about finding the optimal solution within the constraints given to us.
    • Requirements: As stated in Principle 2: Focus on Quality Attributes – not on Functional Requirements, it is important to explicitly document non-functional requirements.
    • Alternatives: List the alternative solutions to the problem, clearly describe the pros and cons of each.
    • Decision: Clearly articulate the final decision leaving no room for ambiguity
    • Rationale: Outline the thought process that resulted in the decision.

    Finally, there is one piece of critical information required: Who has made this decision and when? Appropriate accountability and visibility of decisions is a must:

    In his excellent book Visual Explanations, Edward Tufte provides an incisive analysis of the Decision to Launch the Space Shuttle Challenger. Over 10 pages of detailed analysis Tufte demonstrates the multiple failings of communication that resulted in the shuttle being launched in a temperature too low; resulting in the fatal O-ring failure. The day before the launch the rocket engineers prepared a presentation outlining the temperature concerns. As Tufte describes: “The charts were unconvincing; the arguments against the launch failed; the Challenger blew-up.” One of the most interesting points raised by Tufte was that the title chart and all other displays used did not provide the names of the people who prepared the material.

    We would also recommend not only documenting architectural decisions, but defining the architectural decisions you need to make upfront and identifying the dependencies between them. Following is an example for the architectural decisions required in defining an integration approach for a specific business area:

    Architecural Decision

    It is appropriate to remember at this point Principle 3: Delay design decisions until they are absolutely necessary. What we are saying here is not in conflict with this principle. It is important to clearly understand all the architectural decisions that you need to make; or as Donald Rumsfeld said the known unknowns. Then as more data becomes available you can start making and documenting the decisions.

    Finally communicating the list of architecture decisions, past, present and future has tremendous value. A good practice is to be public with all the architectural decisions and all the background dialogue utilizing social collaboration tools available in the enterprise. Why not make everyone finally understand what architects spend time on. Basically, the unit of work of architecture are the architectural decisions. The difference between what Enterprise Architects and Solution Architects is nothing more than the level of abstraction.

    • FM 1:30 pm on September 21, 2014 Permalink | Reply

      The decision log has been a key artifact I’ve learned to use over the years. I believe it captures not just the architect’s thought process but should reflect the zeitgeist and various constraints of the time. We’ve used it successfully recently to manage a consistent decision cadence in agile projects with little certainty and high discovery.

      You have a few more decision attributes in your list that I think I will incorporate into our next set of initiatives.


      • muraterder 6:47 pm on September 23, 2014 Permalink | Reply

        Great to see that the decision logs are being successfully utilized in agile projects.


    • pkruchten 10:33 pm on September 26, 2014 Permalink | Reply

      Other views on Architectural design decisions (ADD) include:
      J. Tyree and A. Akerman, “Architecture Decisions: Demystifying Architecture,” IEEE Software, vol. 22(2), pp. 19-27, 2005. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1407822&tag=1
      and mine, here:

      One of the key element is the many relationships between design decisions.

      Several tools have been tried to help capture and manage ADD, with not great success.

      Liked by 1 person

    • Charles T. Betz (@CharlesTBetz) 1:08 pm on September 29, 2014 Permalink | Reply

      I would not be quite so dismissive of the power of architecture diagrams. Have written about this here: http://www.lean4it.com/2014/09/thoughts-on-agile-and-enterprise-architecture.html


    • muraterder 9:25 pm on September 29, 2014 Permalink | Reply

      Very good point about the value of pictures and images, which relates to how critical collaboration and communication are to the success of the architecture function in an enterprise. I have added an additional post that touches on this topic.


  • pierrepureur 10:41 pm on September 2, 2014 Permalink | Reply
    Tags: , , , ,   

    Continuous Architecture Principles (6 of 6) 

    This is (finally) the last installment in our discussion of the six principles of Continuous Architecture:

    1. Architect Products – not Projects
    2. Focus on Quality Attributes – not on Functional Requirements
    3. Delay design decisions until they are absolutely necessary
    4. Architect for Change – Leverage “The Power of Small”
    5. Architect for Build, Test and Deploy
    6. Model the organization of your teams after the design of the system you are working on

    In the previous pages, we discussed Principles 1, 2, 3 , 4 & 5. This page will discuss Principle 6 – how to organize teams!

    Principle 6: Model the organization of your teams after the design of the system you are working on, in order to promote interoperability

    The first five principles dealt with process and technology – but what about the third dimension of every IT project we are involved in – people? How does Continuous Architecture impact the organization of software delivery teams – or conversely how can we better architect our teams to support Continuous Delivery? First some scoping considerations here: For Continuous Architecture to be effective, we need to include all constituents in the delivery team – not only those responsible for the build activities (designers and developers) but also the groups responsible for testing and deployment, as well as the groups responsible for requirements (Principle # 4).  Collaboration is a key element of Continuous Architecture.

    Going back to our hypothetical example from our discussion of Principle 5, the IT Group in the case study initially attempted to organize the “WebShop” project resources as a number of Agile Teams, each team being focused on one of the  layers of the system: User Interfaces, Mid-Tier Services, Database Services, Back-end Interface services – and quickly discovered that this approach was counterproductive. Organizing teams in layers did  not promote collaboration, but created  communication issues. In addition, the adoption of Agile techniques varied by teams: the UI team decided to be as “Agile” as possible, while the team responsible for the services interfacing with back-end Systems elected to follow their traditional “waterfall” approach. Using several SDLC approaches simultaneously created more misunderstandings and communication issues: since back-end interface services weren’t ready for testing until the end of their waterfall development cycle, the UI and mid-tier developers had to “stub out” their calls to those services during their iteration testing, which prevented them from testing with realistic test cases and resulted in the majority of the defects being discovered in the QA phase. This in turn resulted in significant unplanned rework to fix those defects. In addition working sessions between the teams were few and far between and that lack of communication contributed to additional misunderstandings resulting in more defects.

    What happened here to our hapless IT Team is that they were the victims what is known in the IT community as “Conway’s Law”. Back in 1968 (according to Wikipedia) computer programmer Melvin Conway introduced what became “Conway’s Law” at the National Symposium on Modular Programming: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”.  This was further elaborated by James O. Coplien and Neil B. Harrison as follows: “If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble… Therefore: Make sure the organization is compatible with the product architecture” (Coplien and Harrison – July 2004 – Organizational Patterns of Agile Software Development).  Putting Conway’s Law to work for you – and not against you – means organizing your teams after the design of the system you are working on, in order to promote interoperability. In this case study, it would have been much better to organize the teams vertically (i.e. by transaction type) rather than by architecture layer.

    In Summary: The Principles of Continuous Architecture At A Glance:

    In this blog, we defined “Continuous Architecture” as an architecture style that follows the following six Principles:

    1. Architect Products – not Projects
    2. Focus on Quality Attributes – not on Functional Requirements
    3. Delay design decisions until they are absolutely necessary
    4. Architect for Change – Leverage “The Power of Small”
    5. Architect for Build, Test and Deploy
    6. Model the organization of your teams after the design of the system you are working on

    Continuous Architectures are designed to have the following capabilities: They are resilient to change, they are testable, they can respond to feedback and in fact they are driven by feedback. The following pages will discuss how Continuous Architecture begins, how it evolves and the role of an Architect in Continuous Architecture, so stay tuned!

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc