Updates from muraterder Toggle Comment Threads | Keyboard Shortcuts

  • muraterder 1:33 pm on September 25, 2016 Permalink | Reply  

    Role of the Architect 

     

    The role of the architect is widely accepted in the world of technology, but not clearly defined.  This blog post provides a summary of the views we expressed in our book[i] as well as in an article published in IEEE Software[ii].

    In general, the term architect exemplifies individuals who make key decisions about the structure and behavior of a system – be that software or other technology areas. Though software architect is the most commonly used term, there are network architects, storage architects, information and security architects. You could even say that any technology subject area has people that identify themselves as architects.

    All these types of architects appear to share the following characteristics:

    • Architects have deep knowledge in the domain of interest.
    • They mostly do not directly implement (some architects can create executable prototypes during architecture sprints or runways), instead dealing with higher levels of abstraction by defining the structure of a system in the domain of interest.
    • They have explicitly or implicitly the authority of making decisions in the domain of interest

    In his book Mythical Man-Month[iii] Frederick Brooks talks about the conceptual integrity of a software product. This is a good place to start for defining the role of the architect – basically they are accountable for the ‘conceptual integrity’ of the entity that is being architected.

    Architects deal with a higher level of abstraction than implementers, developers or engineers, do. Their concerns include the main components of the system and how they interface and they continuously validate the architecture against different scenarios. They need the ability to traverse different levels of abstraction between concepts, models and implementation details.

    The role of the architect in agile development is hotly debated in the industry. Some Agile practitioners believe that there is no need for an overall architecture, since the architecture “emerges” through the implementation of stories and refactoring. We believe that such a view applies only to simple and fairly self-contained projects. If you are architecting a product or try to operate at a large scale you do need to think of the architecture – however, this does not mean that you need a separate architect, but the role of the architect is still crucial to success.

    We recommend three focus areas for defining the role: Unit of Work, Product Focus and the Realized Architecture.

    Unit of Work

    An interesting way of considering architect role is to focus on their key activities. In other words, what is the key unit of work of an architect? Is it a fancy diagram, a logical model, a running prototype? We believe that the basic unit of work for an architect is an architectural decision. As a result, the most important output of any architectural activity is the set of decisions made along the software development journey. Surprisingly, little effort is spent in most organizations on arriving at and documenting architectural decisions in a consistent and understandable manner.

    We can state that, the key responsibility of an architect is to drive architectural decisions to a conclusion.

    We purposely used the term drive to a conclusion rather than make. The term drive to a conclusion implies that the architect engages with stakeholders and works through the options to arrive at a decision. It does not mean that an architect can abdicate responsibility for making sure that architectural decisions are made. An architect must make sure that decisions are made in a timely manner.

    Product Focus

    As explained in our book, we believe that architects should focus on architecting products, not just solutions for stand-alone projects. It follows that the architect should operate as part of a team – in this case a product team. This implies that communication and collaboration skills become highly relevant.

    role-of-the-architect

    Within the context of a single product, the architect plays a key role in the product team. Her/his main responsibility is to balance the demand from the client as represented by the product manager, with the delivery focus provided by the product delivery manager. The architect has to make sure that the architecture of the product is coherent and sustainable. Especially in the initial phases of a product life cycle, there is often a “negotiation” between product management and the “art of the possible”. Managing this conversation is a key responsibility of the architect.

    Realized Architecture

    The real architecture of a system is represented by the code that is running on the physical infrastructure. We will call this the “realized architecture.”We believe that the days of an architecture only represented as a set of documents are over.

    The role of the architect is to understand, influence, improve and communicate the Realized Architecture.

    Therefore, it is important for an architect to understand the code running on the physical architecture.

    Final Definition

    We can summarize our views by defining the role of the architect as:

    An architect is responsible for enabling the implementation of a software product by driving architectural decisions in a manner that protects the conceptual integrity of the software product.

     

     

    [i] M. Erder and P. Pureur, Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World, Morgan Kaufman, 2015

    [ii] M. Erder and P. Pureur, What’s the Architects Role in an  Agile, Cloud-Centric World, IEEE Software Vol 33, No 5, pp. 30-33

    [iii] Brooks, Frederic, 1975 & 1995, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, ISBN 0-201-00650-2 (1975 ed.), 0-201-83595-9 (1995 ed.)

    Advertisements
     
  • muraterder 8:35 pm on July 22, 2015 Permalink | Reply  

    Open Source and Continuous Architecture 

    Setting technology standards is one of the more common activities that Enterprise Architecture groups fulfill. Setting standards is challenging enough when considering commercially available products. The last fifteen years has seen the emergence of Open Source software that has increased the challenges in this space. According to the Open Source Initiative, the term is defined as:

    Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone. Open source software is made by many people, and distributed under licenses that comply with the Open Source Definition.

    Commercially Open Source has been quite successful and acted as a true disruptive source within the software industry. At its best Open Source can be considered to embody all the good things about the internet age. It demonstrates the ability of individuals to collaborate to achieve a common goal. The common wisdom being that multiple people addressing the same problem solve it more elegantly with fewer defects. The Open Source movement has also taught us quite a lot about how communities can collaborate effectively across different geographies and time zones. Though seemingly very democratic, it is interesting to note the concept of a “benevolent dictator”(also known as the “committer”) being key to quite a few of the successful Open Source initiatives. Briefly, the benevolent dictator can be considered the architect, or the person responsible for the conceptual integrity of the solution.

    The impact of Open Source can be seen from the market leading solutions it has given rise to; from Linux, to the multiple projects under the Apache Foundation (TomCat, Camel and Hadoop to name a few well known ones). From a commercial perspective Open Source has also created new business models, where companies provide versions of Open Source software that are supported in a more traditional software model. These have been instrumental for large organizations to feel comfortable in using the Open Source technology. You could say  that in the future we may get to a point where there are only two types of software left: open source and Software as a Service (i.e. software delivered via the Cloud)

    Does Open Source have any significance from an architectural approach perspective? From one perspective, Open Source code has been a huge asset for software reuse. Effectively used Open Source components can significant reduce the time to market of a software development team. On the other hand, Open Source technology creates significant challenges in terms of introducing unknowns into your software code base. This can happen from multiple angles:

    • Commercially, the teams might not be aware of what Open Source licensing they are operating under. This could cause significant headaches if it is found that the organization is not fully adhering to the license conditions. For example, legal headaches when signing a new contract for open source support – e.g. indemnification!
    • The development teams might not be downloading the most recent version of the Open Source component, or more likely they will not be keeping their version of the component up to date with newer versions. This can result in non-performant or defective code existing in the code base.
    • A special challenge is around security risks. There is no guarantee that all security flaws will be fixed rapidly and the alerting mechanisms for known security breaches can be suboptimal.
    • Finally, there is always the possibility of the community losing interest in the Open Source initiative. Resulting in a portion of your code base being orphaned with no one really supporting it or understanding it fully. From one perspective this is no different than the legacy Cobol code base existing organizations.

    From a Continuous Architecture perspective we are very supportive of the ethos of Open Source initiatives. We believe that the code itself, as well as the community models it espouses are tremendously valuable. We would encourage organizations to embrace Open Source and apply some of the Open Source development approaches internally as well; commonly known as Internal Open Source models.  An area where this approach can be used is for orphaned Enterprise Services that the enterprise no longer wants to maintain because there is not enough demand for them. If a few groups still want to use those services, they can continue to maintain them using our internal open source model.

    While implementing Open Source within a commercial enterprise a controlled approach in terms of tracking Open Source usage and addressing the challenges highlighted above is required. We believe that following the Continuous Architecture principles like Principle 4 Architect for Change –  Leverage “The Power of Small”  and Principle 1 Architect Products – Not Just Solutions for Projects will help in addressing the challenges. Both of these principles enable you to manage to scope and context of your code base so that you can keep track of the areas where you use Open Source more effectively. In addition, open source software tends to be more cloud friendly than proprietary software. This is where applying Principle 5 – Architect for Build, Test  and Deploy comes in handy.

     
    • Robert Baty 9:03 pm on July 24, 2015 Permalink | Reply

      Good post, at my current employer we have wrestled with Open Source for some time now. We have a process to review the licensing, track the usage and ensure the open source is from a more reputable provider like Apache, however, it still seems lacking.

      Developers we hire nowadays expect to be able to download and use whatever tool they like and get frustrated working at a big shop with some of the bureaucracy and security policies in place. How do you balance the need to allow creativity and innovation in solving technical problems with the corporate governance of large organizations?

      Like

  • muraterder 9:52 pm on February 2, 2015 Permalink | Reply  

    Business Context for Architecture – Using the Right Term? 

    In 2004 we published an article in IEEE IT Professional titled ‘Defining Business Requirements Quickly and Accurately’. In hindsight we probably should have called it ‘Defining the Business Context for Architecture’.

    Eleven years have passed since this article, but we believe that the key tenets of the article are still valid. But have the terms of the IT industry changed? In particular, I am interested in views on use-cases vs. user stories.

    In 2004 we used the concept of use-cases to define how we can provide a dynamic view of the business. However, these days though the term use-case is quite widely used, we believe that it has lost its core meaning. Similar to Kleenex and Xerox – the brand is so successful that it is used to represent something more general than originally intended.

    Do we really find many software development teams that create use-case models and write use-case descriptions – probably not. Instead everyone is focused on user-stories and agile development, or at least pretends to be. According to Wikipedia a user story is defined as:

    “In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.”

    The challenge with this is the scope of a user story. A few sentences are a great way of documenting requirements on an index card; but are they sufficient to operate at a larger scope? We address this by  grouping user stories into themes, or what we call user story themes.

    So, should we still use the term use-cases or switch to user story themes? Let us now present our key idea about providing business context to an architecture to illustrate our point.

    The first step in the developing an architecture is to understand the functional scope of the product or project we are building. We use value chains to better understand and describe this functional scope. The objectives of developing a value chain are to:

    • Understand the “why” and “what” of the business. Why are we in business? What are the core activities that provide value to our clients and us?
    • Understand the “how” of the business. How do we actually execute within the core activities of our business?
    • Understand the “whom” of the business. Who are the internal and external users of our technology?

    The role of the “Value Chain” is to depict activities (“chevrons”) of the Enterprise that are involved in generating value, as well as the supporting areas. The following example depicts a sample value chain for a loan servicing organization.

    Value Chain

    A value chain provides an overview of the business by depicting major processes that collectively generate value for the organization and its clients. A value chain is a long lasting view of the business. As long as the core business does not change, the same value chain can be used by the organization for years. One of the first authors to introduce the Value Chain concept was Michael Porter in 1985.

    The value chain is great at setting the high level context, but to drive architectural definitions we want to animate the value chain. For this in 2004 we proposed using use-cases, which was first introduced by Ivar Jacobson in 1992. For the rest of this blog we will put “use-cases / user story themes”, in place of where we had use-cases.

    Let’s use the loan servicing organization from our previous example to further expand. We know from the value chain that the first two chevrons are Loan Application and Funds Disbursement. But what actually happens and who is involved in these activities? We can get this information by looking at the “use-cases / user story themes” for each chevron.

    Value Chain and Use Case

    As can be seen from the above diagram, we now know more about how our business operates. We have determined three main events (Apply for Loan, Disburse Loan and Pay Fees), which we will call “use-cases / user story themes”, and eight roles (Applicant, Guarantor, Lender, Credit Bureau, Core Processing, Loan Origination, Servicing and Designated Recipient), which we will call actors. The “use-cases / user story themes” tell us the “how” and the actors the “who” of the business.

    Going back to our Loan Servicing Organization, we find that we have five external actors, the Applicant, Lender, Guarantor, Credit Bureau and Designated Recipient. From this we can understand the core business revolves around connecting three of these actors, the Applicant, Lender and Guarantor. We can also infer that the organization in question is not a lender itself, but acts as a broker between the lender, the applicant and the guarantor of the loan.

    We can go further and create a high-level sequence diagram outlining the major components that will be involved in the ‘“use-case / user story theme”:

    Sequence diagram

    This sequence diagram highlights the need for one major system for Originations and two supporting components; an Imaging Service and a Formatting Service. You can see that we have started making architectural decisions already in the process of drawing a sequence diagram. When we make decisions on such matters it is not usually in confines of one sequence diagram, but across the breadth of the overall architecture. Other sequence diagrams we would have developed would have pointed out a need for common services such as the Imaging and Format services.

    Now that we have provided a brief overview of how we want to animate the value chain, we can come back to our question.

    Should we stick with the concept of use-cases? I believe that use-cases provide an excellent approach to identifying scope and keeping the focus on the end user. However, will the term be misunderstood?

    Or, should we acknowledge the relevance of user stories and group them into user story themes?

    Finally, does it really matter? You might say one challenge with the software industry is that we keep on re-inventing the wheel and leave behind key lessons at each ‘iteration’ of fashionable terms.

     
  • 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?

    Gehry

    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.

    Collaboration

    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…

      Like

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

        Like

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

      Like

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

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

        Like

    • 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:
      http://pkruchten.files.wordpress.com/2009/07/kruchten-2004-design-decisions.pdf

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

      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

      Like

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

      Like

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel