Identify Indirect Stakeholders with System Context Diagrams

April 16, 2014

A Systems Flow consultant has skills that tend to fall in the triangle of technical, business and organizational excellence. One common and repetitive case of project dysfunction where this overlap brings real benefits is that of the “Operational Business Stakeholders Missing from Business Requirements.” Here’s how it usually goes:

  1. Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
  2. He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
  3. The requirements (hopefully) clearly state the end-user and product/service-centric objectives
  4. But how the end-users and the new/enhanced product or service will be supported operationally is completely missing
    Read more


Integration – Send Me a Message

March 31, 2014

I recently had the opportunity to work on a project where we were bringing in a vendor product that required data integration with a number of our client’s in house transaction applications. We needed to determine how the internal applications would integrate with the new product.  I figured the timing was right to build on my prior blog on messaging, and provide some additional guidance. Read more



Issue Resolution – Celebrate Your Success

March 3, 2014

This blog is the third in a series of posts designed to help technical leads get over the hurdles that inevitably pop up during any complex implementation; a series that was started by Understanding the Problem and continued in Determining a Solution.

With the course set and the implementation of the recommended solution underway, it’s time to finish strong.  Read more



Issue Resolution – Determining a Solution

February 19, 2014

This blog is the second in a series of posts designed to help technical leads get over the hurdles that inevitably pop up during any complex implementation; a series that was started with Understanding the Problem.

Once the problem is sufficiently understood, it’s time to roll up your sleeves and get down to business. Read more



Think Strategically, Proceed Practically

January 20, 2014

Knowing the strategic solution is only part of the challenge. Let’s assume you are able to establish the “right and just” solution either because your enterprise has well documented target architectures and roadmaps or your solution has a well established “best practice” pattern you can apply.

Take a moment to savor your success, but only a moment! Now let this sobering thought sink in – your awesome design brings zero business value to your organization until it is instantiated and running in production. Zero. No business value at all.

In most cases, designing the strategic solution is the easy part of the challenge. Let’s review the remaining roadblocks between you and providing business value, then discuss the winding path to success.
Read more



Hey, Did You Get My Message?

January 6, 2014

There are different ways for applications to talk to one another. These can include:

  • File Transfer
  • Web Services
  • Shared Data
  • Messaging

All have their strengths and weaknesses but for now let’s focus on the advantages of messaging.

Read more



Documenting Design Decisions

December 16, 2013

We previously discussed Options Analysis – our method for evaluating multiple viable technical solutions.  We also facilitate numerous smaller design choices at all levels of the architecture.  We often need to document these as “design decisions,” and use a common approach and format to document at all levels of design (conceptual, logical, physical, component, etc.).
Read more


Prose: Great for Novels, Lousy for Solution Design

December 3, 2013

While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation.  When it comes to design documentation, more is actually not better.  We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the binding.  We recommend not doing this!
Read more



Cost, Time, & Architecture – The Zen of Options Analysis

September 9, 2013

Solution architecture is typically designed within a project context. Although we focus on the right process for this design activity frequently in our blog, the intersection of that process with the process of delivering an actual production solution is very important. Constraints are a key reality in projects, and often they compete with achieving the “right” architecture. A process to guide a design through this gauntlet of project constraints is why we created our “Define Solution Options” process.

Read more



The Art of Accepting Feedback

January 24, 2013

As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. Read more



Next Page »