The Art of Accepting Feedback
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
Don’t Get Distracted by the Document
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
It’s Not About the Tool
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.
The Solution Architect’s Path to Success
Welcome to today’s blog. Sit back and relax. Close your eyes. Take some deep relaxing breaths. Envision a Utopian architecture project delivery:
- Scope is clear and agreed upon,
- Requirements are carefully crafted,
- Read more
When “Good Enough” isn’t Good Enough
So what is this picture? The unhelpful answer is that it is a photo of a sign with a burlap sack on it. I’d like to say that my community thought it would be a cute Halloween decoration, but I cannot. The truth: it is great example of the “good enough” anti-pattern. Read more
How to Flub Your Design Review
We would like to share some common approaches that consistently lead to failed design review meetings. They are somewhat embellished for effect, but, sadly, are not all that far removed from real world experiences. If you are interested in an ineffective design review, please be sure to: Read more
Measure Thrice, Cut Once
Make sure that your designs are accurate. Read more
Buy vs. Build Your Software
Most organizations shift back and forth between building and buying software solutions in time with executive leadership shifts. To avoid the resulting IT portfolio churn, each organization should establish the IT strategy that best supports its business model – including decision criteria for build vs. buy – or be condemned to holy wars on every solution design. Our default recommendation is “buy,” and here is why. Read more
Document for Success, not Defense
A meeting recap is not a design document. Read more
Avoiding Accidental Choices
“If you choose not to decide, you still have made a choice…”
Peart, Neil. “Freewill.”Permanent Waves. Mercury 1980.
With frightening frequency, we see technology projects become subject to “accidental choices“, when rigor is bypassed without a conscious choice having been made to do so. Read more