• Business Requirements. Written and Approved. Check.
• Functional Requirements. Written and Approved. Check.

Seems like everything is covered. Except… where’s your traceability matrix? You have one, right?

If you don’t, you’re missing one of the best tools for ensuring a successful project.

By creating links – traces – between your business requirements, functional requirements, and test scripts you reveal a number of critical things about your project:

• Is each business requirement being implemented by a functional requirement?
• Is each functional requirement being driven by a business requirement?
• Is each functional requirement covered by a test script?

A full matrix might look something like this:

As you can see, a 1:1:1 ratio between business requirements, functional requirements, and test scripts doesn’t always exist:

• A single business requirement can trace to multiple functional requirements
• A single test script can trace from (“cover”) multiple functional requirements
• Multiple test scripts might be necessary to cover a single functional requirement

What you can also see is that your project has some serious problems.

Without even looking at the actual text of the business or functional requirements, the traceability matrix raises a number of red flags:

• BusReq4 does not trace to a single functional requirement. This reveals a gap in the project’s design.
• FuncReq6 does not trace to a test script. By creating a traceability matrix you can discover and correct a gap like this during the development phase, not during the expensive post-release phase.
• FuncReq7 does not trace from a single business requirement. Hmm…where did this requirement come from? If it’s not driven by a business requirement, what is it doing in this project? This is an indication of possible scope creep.

We’ve just touched the surface of what a traceability matrix can reveal about your project. Future discussions of this topic will probe a little deeper into the rewards and risks of maintaining a traceability matrix.

1. Leadership & organization
2. Business acumen
3. Technical chops

Normally, labor in a project is divided up according to these specialties – i.e. developers have the technical chops, business analysts have the business chops, project managers organize themselves and everyone else. Throw them all into a pot, stir vigorously and…presto! A successful project.

Hardly.

At the heart of every successful project is usually a person or two who seems to posses key slices of at least two of these skill-sets. It could be:

• A project manager who has deep experience in the business domain in which the project is executing, and is able to do double-duty as requirements facilitator.
• A business analyst who understands and appreciates the architectural implications of the solution being implemented, and even knows the enterprise’s technology strategy – a true Business Archtiect.
• An IT Architect who, in addition to having his software patterns down pat, is also a strong leader able to bring warring stakeholders to consensus.

We at Systems Flow long ago recognized the special role these “utility players” have in successful projects.

Over the years we’ve evolved this into a “sacred triangle” of skills that all our consultants are measured against, both during recruiting and in our employee development program:

Even though each individual consultant is usually engaged with a client for one area primarily, we recruit and cross-train all our consultants in each area and consider them core for success. We even have detailed process, guidelines and samples/templates for things as sublime as Logical Design Artifacts, and some things as mundane as meeting recaps.

Contact us to learn more about our process – whether you’re looking for help, or looking to join our team!

“Through practical learning opportunities based on real-life experiences and case studies, attendees at the Conference will have the opportunity to gain a valuable insight into:

• The differences between EA and Enterprise Transformation, and how they relate to one another
• The use of EA to facilitate Enterprise Transformation
• How EA can be used to create a foundation for Enterprise Transformation that the board and business-line managers can understand and use to their advantage
• How EA facilitates transformation within IT, and how does such transformation support the transformation of the enterprise as whole
• How EA can help the enterprise successfully adapt to ‘disruptive technologies’ like Cloud Computing and ubiquitous mobile access.”

Yum!

We have blogged previously on our corporate stance regarding the value of conferences, and we are very pleased to have been asked to contribute to this one.

I will be presenting another chapter in our Investigative Architecture canon, Investigative Architecture: Understanding Systems in a Business Context:

“A foundational skill for an architect is the capability to rapidly assess and document “as is” and proposed architecture and communicate clearly to business partners. A carefully scoped and formatted diagram is a powerful vehicle for clear communication. A specific diagram – the business context view – provides a rapid method to describe a solution in business language. This instructional session presents concrete techniques and structured rules of thumb to guide the development of business context views at both the enterprise and solution level. We will walk through a case study in order to illustrate the techniques, and present strategies to map to and from other types of views within Systems Flow’s core set of “Investigative Architecture” diagrams, which we presented at previous Open Group conferences.”

We are also collaborating on a presentation with some client colleagues on the power of Infographics for “selling up,” Using Infographics to Communicate Architecture:

“Successful communication to non-technical CxO level decision makers is a critical aspect of any enterprise transformation.  A multi-pronged approach consisting of metrics, supporting facts, and “eye candy” targets both the rational and emotional sides of your audience. This presentation shares a case study of a large, global enterprise and its recent experience with infographics as a powerful vehicle for successfully selling change.”

We hope you will join us in San Francisco!  At the very least we expect it to transform our weather, if only for a week…

Investigative Architecture is the term we coined back in 2008 for our approach that facilitates the rapid assessment and documentation of ‘as-is’ and proposed IT architectures.

We developed this Investigative Architecture approach a decade ago in support of our enterprise and solution architecture consulting services.  Success in any architecture engagement requires quickly sifting through a myriad of internal and external information sources at all levels of quality and completeness and rapidly converting this sea of information into useable knowledge.  This, in turn, requires a repeatable, structured approach for gathering information from internal stakeholders and documents, as well as performing focused research for publicly- available product and industry information.  We have applied this approach in order to understand hundreds of enterprise level solutions and have trained countless others to do the same.

This Investigative Architecture Workshop will build your skills in a workshop that is a balance of expert instruction and hands-on practice.

Here are some key aspects of the training:

1. Sleuthing Skills - Where can you go for information?  How do you detect the clues?  What artifacts exist than can be leveraged?  What is known?  How do you know the right questions to ask?  Our experienced trainers will offer some important observations and tips on how to go about tackling this task.
2. Diagramming – Using the right diagrams makes the architecture clearer to everyone (including you) AND helps you ask the right questions.  You will learn when to use which diagrams and the simple notations behind the diagrams, primarily UML-based.  This is where the hands on aspect of the course will really kick in!
3. Listen, Learn, and Do – The blend of teaching, case studies, and hands on exercises will help ensure you remember it all when you take your sharpened skills back to your enterprise.

This training has something to offer individuals possessing all levels of experience, from highly advanced practitioners looking to add another tool to their tool-belt, to developers looking to learn more about IT architecture and/or architecture diagramming.

To learn more, read some of our Investigative Architecture blog articles or review some presentations we have given on the topic.

Register today or contact training@sysflow.com with any questions.

Pulling the curtain back a bit further, I can tell you that there are legions of these in my neighborhood. Many months ago, road construction required some long term rerouting of local traffic flow, so a large number of detour signs were installed.  Still months ago, the construction completed and the signs were no longer needed.  The correct solution was to remove the signs; the “good enough” solution was to cover them with burlap sacks.  It was, no doubt, quicker and cheaper: it solved the immediate problem.

As architects we frequently face “good enough” solutions employed to solve an immediate problem. Just as frequently, once the “pain” of the immediate problem has been relieved (or even reduced), the interest in implementing the correct solution fades.  We have some strategies for avoiding these situations:

1. Strive for strategic solutions that meet tight budgets and timelines. Higher costs and longer timelines sometimes correlate with better solutions, but not always. Determining if a strategic solution can be implemented for the same (or close) impact requires that the project employ math to compare the cost and timelines, not emotion. The gut reaction of almost every project manager will be to assume the strategic solution will cost more and take longer. We have all been a part of “good enough” solutions that – not surprisingly – took much longer than expected to implement.
2. Probe the reality of the deadline. Frequently a “good enough” solution will be implemented to meet a deadline that is not as immutable as it seems; a deadline which shifts multiple times through assorted scope modifications.  This can result in a spaghetti mess of a solution after spending more time and money than would have been spent doing it right from the start.
3. Help the decision makers understand the facts. Nothing is free.  A solution cheaper than the strategic solution is cheaper for a reason.  The project will carry more delivery risk, the solution will skip functional and non-functional requirements, or the enterprise will be less prepared for future technology needs.  A business can always choose to make choices like this, but they need to be conscious choices.

None of this is to imply that there are not situations where a “good enough” solution is, well, good enough!  The analysis associated in 1-3 above will identify those scenarios.

It is also critical that these non-strategic design choices be documented.  We will also share some additional strategies for documenting and managing these non-strategic design decisions in a future article.

With regard to the burlap solution, I will keep you posted and share the outcome when one of the  sacks blows off and unleashes a phantom detour…

1. Assume that the stakeholders understand the meeting goals, the design format, and the diagram notations. It should all be pretty self-explanatory.  Focus on slogging through the content.
2. Read the design document to the stakeholders as if it was a novel. It’s riveting material: people go to bookstores to hear authors read their work all the time.
3. Wing it. You’re smart enough to discuss your own document without preparation.
4. Don’t set business context. It’s a technical design review, why waste time on the business?
5. Distribute the design document minutes before the meeting. Frankly, they probably would not have read it in advance anyway.  If they complain, tell them that.
6. Be defensive. You need to protect the sanctity of your design.  I mean really! Who’s the architect here?
7. Allow tangential discussions. In fact, pursue a few yourself.  People love interesting side discussions to liven up a “single topic” meeting.
8. Own that design! There is no “us” or “we” in MINE.
9. Talk nonstop without pausing to breathe. You will complete more quickly without the interruptions.
10. Worry about capturing the comments later. If it was important, you’ll remember it.

Joking aside, a design review is an activity vital to the vetting of a design – part of our measuring thrice philosophy – and critical to gaining stakeholder buy-in.  We provide our team with a core set of guidelines that avoid the pitfalls listed above. We ensure that design reviews receive the focus and attention that they deserve.  These  boil down to two critical steps:

1. Respect your colleagues’ time. Your design review needs to be a well-orchestrated event which requires preparation and practice.
2. Respect your colleagues’ opinions. The goal of your design review should be to vet your design with others.  Refer to the “Strengthen the Design” item in our Architect or Diplomat article for our philosophy on feedback – good, bad, useful, or otherwise.

We will delve into the details of running a good design review in a future article, but in the meantime for some additional helpful tips, try our articles on facilitation and diplomacy.  And please avoid 1-10 above!

Like almost every homeowner I know, I’ve become a de facto handyman. But while I enjoy it, I don’t consider myself especially good at it. Truth be told, there are a few extra holes in the walls of some of the places I’ve lived in. For this reason, when I bought my new home a couple of years ago, I decided that I wanted to teach myself to do things right the first time. I wanted to approach my little jobs with a healthy sense of my own limitations in the mechanical realm. Now I will often sketch out what I want to do on a piece of scrap paper, and then come back to it later to see if I can re-create the logic that got me to those measurements. It’s working! My life is not perfect, but more projects are going in right the first time: It’s very satisfying.

When designing large information systems, a confusing specification or a misplaced line on a diagram might cost an hour or two of the architect’s time to research and fix during design. During systems integration testing, that same error might cost that same architect’s hour plus 50 to 60 hours for developers, testers and other resources. It might even result in a delayed implementation. The first time you see this happen, it is a bit bone-chilling. Frankly, it’s an experience I would much rather avoid. For this reason, spending a bit of extra time during design to chase down any niggling doubt should be a non-decision. Of course, we can’t rule out every possible error (we remain human), but developing an instinct for what needs to measured again is part of what makes us valuable – along with the discipline to insist on it when needed. Pick up the phone. Send the extra email. Set up an additional half-hour meeting with that one subject-matter expert who missed the design review. Keep wandering around to that developer’s desk until you catch her. Go ahead and make yourself take that third measurement, just to be sure.

For me, the home handyman experience has helped re-enforce good work practices in the professional space. It seems that there is a need to visualize each design in a way that says: “This is the center of the clean, white wall in my living room. I have measured this carefully. I know I need to drill right here. Yes.” There will be no extra holes. And it will be very, very satisfying.

The most challenging tasks undertaken by a Technical Lead will never show up on a project plan.  They arrive, without notice, in the form of urgent emails and frantic phone calls.  The sky is falling…and it’s your job to lift it back up.

How you react can mean the difference between a successful, on-time, on-budget, quality delivery and… well… a mess.  By following a few guidelines and maintaining laser-focus on the critical path to issue resolution, even the most arduous issues can be positively resolved.

1. Take a deep breath. A common mistake when confronted with an urgent issue is to panic.  Tech leads often reflexively light up the phone lines or fire off a series of emails in an attempt to find an immediate solution or escalate to a project manager.  The problem with this approach is that, more often than not, neither the actual issue nor its true urgency is yet understood.  This can result in unnecessary escalation or miscommunication, which can undermine your ability to resolve current and future dilemmas.
2. Avoid focusing on how and why things went wrong. When the Titanic started taking on water, the role of the iceberg became more or less irrelevant.  While it is tempting to try to immediately assign (or avoid) blame, it is much more productive to focus on resolution.  Avoiding finger-pointing will also help keep all stakeholders engaged and pushing in the same direction, regardless of the mistakes they may have made.
3. Understand the Impact. Now that you’ve calmed things down, it’s time to roll up your sleeves.  The initial goal is not to dissect every minute detail of the problem at hand.  Rather, the focus should be on gaining enough of an understanding to accurately answer some basic questions.  What teams are affected?  What are the potential impacts to the plan and budget?  Notice that we are still not attempting to identify potential solutions.  This phase of the process is primarily about gathering information.  This information will make up the foundation upon which a resolution will ultimately be built, and the quality (not quantity!) of the data will be the key ingredient to a successful solution.
4. Engage the stakeholders. Once the affected project teams have been identified, SMEs from each group need to be engaged, to analyze the problem and suggest their roles in possible solutions.  This is another step where a technical lead needs to lean heavily on the various project teams.  Remember why you’re engaging these stakeholders; they are the experts in their areas and have the contacts that you’ll need to leverage if escalation is required to get the job done.

With the problem identified, information gathered and stakeholders engaged, you are ready to proceed to the next step in the issue resolution process.  It’s time to identify the solutions that could save the day! Stay tuned…

“Speak softly and carry a big stick: You will go far.”
- African Proverb

Diplomat is a key role that Systems Flow’s architects often fill for our clients. Software projects and change initiatives inevitably bring disputes and disagreements over requirements, scope, priority, standards, architectures and solutions. While most project management disciplines offer approaches to managing issues, we have found a basic mantra that keeps us on track:

“Stick to the facts.”

It sounds simple, but actively discovering and clearly documenting the facts of a project disagreement is never easy. Whilst spelunking into the murky depths of these types of problems, here are some “Dos” and “Don’ts”:

1. Give them options. It may come as a surprise but good IT Architecture consultants don’t make decisions, they facilitate them. We don’t run our client’s business, or develop or support their software portfolio. What we do effectively is understand technology and its business context, and know our stakeholders’ motivations. Lay out all options to resolve the problem, from the sublime (e.g. a full-blown costly, solution) to the ridiculous (e.g. do nothing).
2. Be Switzerland. This is a instruction we frequently give our new consultants. The only way to make true peace is to not take sides in a battle. Be impartial, stick to facts, faithfully advise of any risks and benefits for any option you propose and know your escalation path if the debate becomes too heated to resolve on your own.  Also, even when tasked with representing one party in a dispute, the perspective should not change.  This is not debate club – deal in facts! Systems Flow is frequently looked to in times of trouble – by all parties in a dispute – because we are consistently fair and fact-based in our approach. Follow these rules and you too may become indispensable.
3. Don’t get emotionally attached. Part of defining options involves some level of solution design, architecture best-practices, etc. Pride in your options analysis artifact is inevitable, but beware of over investing in your own idea. Be focused on resolving the dispute at hand, focus on facts and remember that your value will always be in acting as the Switzerland of your organization. Let your solution go if it doesn’t pass muster with the team.

Here are some example problem cases and approaches to “get at the facts”.

Stay tuned for a more detailed series from us on Architecture Issue Resolution.

1. Your business should be your business! Unless you are in the business of producing software, producing software is a distraction from your core business objective. Time spent producing, maintaining, and supporting in house software is time not focused on whatever your core business goals might be. If you happen to be in the business of producing software, focus on your product and your customers needs, and not on building in-house tools, for the same reasons.
2. Your genius will be somebody else’s genius someday. In house solutions tend to be led by and require reliance on a few (or one) key employees. If (when!) they leave, the solution becomes much more difficult to support or enhance.
3. Contractual accountability has its perks. When you purchase external products, you have contracts and service level agreements; both provide leverage to resolve issues and achieve satisfaction. When you build internally, you may have a good relationship with the team upon which you rely, but otherwise have very little leverage to make your concerns a priority.  See also #2.
4. Expertise can be bought. An off the shelf product comes with many person-years of knowledge, fixed mistakes, and best practices. You may have an extremely sharp team, but some lessons just need to be learned.

That’s not to say there are not sometimes valid reasons to build:

1. Your business need is very unique. If there is no off the shelf solution to buy, clearly you have no choice but to build.
2. The rate of business change is high. If the solution supports a segment of the business which requires a high number of ongoing changes to the solution, more agile change can be effected internally.
3. A facet of your business IS the product you need. For example, if you are a company that sells a sales platform, you may want to eat your own dog food and use that platform for your own sales.

When you do determine that building is the answer, be sure to identify the risks and make the decision with your eyes wide open. Also, buying software is no panacea – you need to identify your requirements and perform responsible product selection – but that is a topic for another day!