Lies, Damn Lies, and Traceability

December 17, 2012

In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements that creeped into your project.

Too often, however, project managers see the steps in a project from the point of view of items that simply need to be checked off: Read more



Type A’s Needed!

November 26, 2012

We write frequently on this blog about our proven method to deliver IT architectures based on industry-standard tools and approaches like UML and IT Risk Management. We also write about the critical intangible skills that an architect needs to succeed, such as meeting facilitation, diplomacy and organization. One needs to be steeped in all these areas – as well as to form a strong “magic triangle” of technical/business/management skills to really succeed.
Read more



Don’t Get Distracted by the Document

October 16, 2012

This may seem like an odd blog coming from a company that is so deliverable focused, but it isn’t. A design document is not just a document, but a powerful tool for figuring out an architecture. However, it is easy to get caught up in the “task” of completing the design document and lose focus on deeply understanding the architecture.
Read more



Pre-Requirement Estimation for IT Projects

September 24, 2012

Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objectives of the change, and what are the requirements a change must meet to satisfy the objective.

Implementing the change usually starts with someone needing to know what the change is going to cost!

Read more



It’s Not About the Tool

September 6, 2012

For practically every profession under the sun there are tools that make the job easier. From bakers to builders, everyone has their choice of implements to ply their trade. Naturally these tools will range from entry level, toy tools to expensive gadgets with more features and sophistication. Enterprise architecture is certainly no exception.

One of our primary tools for designing architecture, of course, is a modeling tool. Modeling tools help us visualize our design into standard, in our case UML, models. There are a variety of these tools in the marketplace, ranging from basic “drawing style” tools to far more advanced suites with “model awareness”, version control, team collaboration capabilities, etc.

Read more



System Architecture Diagrams

August 13, 2012

Diagramming software systems is still a largely undisciplined activity, despite the many advancements in notation and methodology made over the last 10-15 years.

The typical “Systems Architecture Diagram” profile of a large organization goes something like this: Read more



Develop Your Architectural Risk Radar

July 31, 2012

Risks are part of life. There is uncertainty everywhere. And as more and more of our lives and businesses depend on IT, the risk of IT failures and problems is a critical thing to be able to identify, understand, document and – ultimately – manage.

Architectural Risk is a critical discipline in the Systems Flow process. Its a huge selling point in the “design process” sales pitch we are often called on to deliver, usually not to prospective clients but rather to recalcitrant stakeholders or projects sponsors who need to be convinced to spend time in their projects sorting out architecture and design before diving into coding. Read more



Value-driven Status

July 4, 2012

If you work in a professional environment, you inevitably have to communicate the status of your work to your manager. If you are in the professional services business, then you have an even tougher “manager” – your client.

Read more



Mental Momentum: Unsticking a Stuck Design

May 31, 2012

Investigative Architecture is our “bread and butter.” We facilitate meetings with stakeholders, understand what they have or what they want, and use diagrams to rapidly drive to a clear consensus regarding what is there (“as is”) or what should be there (“to be”). We have refined our approach over many years into a clear, well defined, proven methodology. We write articles on our approach, we mentor clients, and we sell training.

So why am I stuck? Read more



10 Tips for “Freestyle” Diagrams

May 24, 2012

We have made clear, and will continue to do so – in assorted blogs, tweets, and diatribes – the importance of consistent notations for diagrams. This was a significant driver behind our adoption of UML as our diagramming standard.

None-the-less, there do come times when we are forced to work “freestyle.” Read more



Next Page »