• Enterprise Architecture

    Stop blaming enterprise frameworks and focus on business alignment


    Enterprise Architecture helps an organization
    realize its competitive advantage.


    “The entire purpose of enterprise architecture frameworks is that they’re supposed to let you accurately and consistently describe architectures. If they can’t do that — if they can’t describe how SharePoint and your ERP suite fit together with everything else you’re running or will want to run — then what value do they provide?” Bob Lewis commented in his CIO magazine article, “The dark secrets of enterprise architecture.”

    Bob Lewis continues with what he calls secrets, but they seem to be more opinions. Expressing that “One reason EA frameworks and methodologies fail so often is that they are, in the end, waterfall in nature.” Many of today’s frameworks did begin in the 1980s where software delivery was waterfall and the TOGAF architectural development method (ADM) at first glance may appear waterfall; however, the ADM process is a guide and TOGAF recommends leveraging the steps as they work best
    for the organization. ADM is not an immutable process that an organization must follow exactly as documented.

    The frameworks are not ‘broken.’ The difficulties that enterprise architecture (EA) is facing are not from the tools and methodologies, but with its alignment with the organization. Still seen as an IT role, enterprise architects are continually left out of key business strategy and planning sessions. The perception of the role needs to change.

    Diann Daniel defines EA in her CIO Magazine Article, “The Rising Importance of the Enterprise Architect” as “the process of aligning a business’s strategic vision with its information technology. It connects different business units for synergistic communication and collaboration, creating a more seamless customer (or end-user) experience, “

    One tool for this alignment is capability mapping; which provides a view of the enterprise that both business analysts, and IT architects could use to design current and future systems. It defines ‘what’ the business does, it does not try to explain the where, why, or how it is accomplished. It is not focused on architecting the solution as the article is trying to tell us, but aligning the organization and IT.

  • Delivery,  Technology

    Leverage Automated Delivery to have Frictionless Software Delivery

    The goal of CD is to be able to release software frequently,
    and reliably, in a frictionless manner.


    By Daniel Horton

    “By now it should be clear that the only way to create value is to release. Testing your products against the marketplace is crucial for the agility of your organization,“ Don McGreal wrote in his book “The professional product owner.” An organization’s ability to release features to its customer base in a fast and reliable manner is a differentiator that we see in many industries. It is the difference between being the top company or the runner up.

    Each client I meet has the same problem. They are inundated with manual processes, procedures, and habits that have built up over years. The statement “it’s just how we do it” is often used. However, these habits are the reason they cannot move forward. The focus is too much on the deliverable and less on the process of delivering. Thoughtworks Studios sums it up well in a white paper on agile release management.

    “Many organizations have a release process that takes hours or days. Why is this so? The most common reason is that releasing new versions of software is predominantly a manual process that involves changes to many separate systems. Operating systems, infrastructure, and middleware must be configured, and their state verified.”

    Manual processes increase the percentage of errors. Coordination becomes more difficult, and the correct procedures are normally not written down for teams to follow. Everything is done based on experience and memory. Additionally:

    “Another major contributory factor to painful releases is poor collaboration between the people involved in delivering software. Developers, testers, DBAs, operations staff, and managers all need to work together from the beginning of every project to ensure its success. Instead, it is typical to see developers throwing work over the wall to testers, testers entering bugs into defect systems rather than working with developers to fix them, and the operations team trying to deploy software that is not production ready, and in many cases, hasn’t even been tested in a production- like environment.”

    Many of these issues can be reduced and even eliminated with a clear focus on release management, automation, and communication. Start small and focus on a vertical slice that cuts through everything. Add metrics to show the benefits of your changes and your on the right path for success.