Posts

Showing posts from December, 2007

Engineering elegance

I came across this quote on definition of engineering elegance by a French aviator and author Antoine de Saint- Exupéry: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Is this statement applicable to software architecture? Aren’t architects constantly trying to add features that fulfill more and more functional and non-functional requirements? Aren’t multiple layers of security always good? Wouldn’t installing a .NET framework 3.5, for example, is better than .NET 3.0, because it has more features?Perhaps those who see the power in this quote are the architects who are able to truly understand the essence of a business problem; it is those who can skillfully control the scope. But is this applicable to the software architecture domain as it stands now? Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Software Architecture Conferences and Events

The Software Engineering Institute maintains a comprehensive list of "upcoming conferences, workshops, and calls for participation that explicitly include "software architecture" among their topics of interest." This is a good place to start if you're looking for an opportunity to share thoughts with like minded individuals outside of your immediate circle of software architecture contacts. Research each event with care, as different user communities look at architecture from a different lens.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Technical and Business Architecture

If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission. It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure. In mature organizations both software architects and business analysts speak a …

Selecting COTS software under pressure (Forrester and Gartner)

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select. The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection element…

Diplomacy

As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing. In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think. Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the…

Diplomacy

As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing. In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think. Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the…

Advice for apprentice software architects

The software architecture discipline has matured to the point where the core tool bag for architecture analysis and design can be learned by any serious software engineer. But this doesn’t mean that architect’s experience is no longer an important attribute of architect’s character. The best way to learn is by doing. To quote Lakota Indian saying: "Tell me, and I'll listen. Show me, and I'll understand. Involve me, and I'll learn." Apprentice architects must seek out opportunities to work on architecturally significant aspects of various projects. Diversity here means working on projects with different SDLCs, projects of different scope and size, and projects across different functional domains. Diverse experience – preferably across different organizations – will enable an apprentice architect make better decisions in the future as the repertoire of skills and knowledge grows.Everybody wants an architect with 10 years of experience, but nobody wants an architect…

Globalization and Software Architecture

When I interview potential team members I always ask the question: “What is the impact of globalization on our company and on our clients?” This is not an easy question to answer and I’ve seen recent college grads and seasoned leaders alike cringe when they hear this. The topic of the global economy is familiar to the IT folks. Many practicing architects are leveraging or at least familiar with the outsourcing software development models. But thinking beyond software architecture – what impact does globalization have on the business problem you’re trying to solve? Perhaps the problem you’re trying to solve is now nonexistent, or perhaps the complexity of the problem just increased by a factor of ten.“What is the impact of globalization on software architecture?” This question I will try to answer in this blog in the near future. With no clear answers this topic is a zero day problem for pessimists and a vibrant opportunity for optimists. If you’re looking for a primer on the general t…

Criteria For Failure

Every project team asks themselves, implicitly or explicitly, what are our criteria for success? Depending on the range of the stakeholders involved you’ll get answers from the superficial (e.g. “users of all skill level can use software”) to the goal oriented (e.g. “identify the safest and most viable customers who need car insurance”). It’s easy to talk about success – especially non-quantifiable success.

The Firebrand Architect philosophy encourages you take a step further and pose a question: “What are our criteria for failure?” In other words – when we look back a year from now how would we know for sure we have failed to achieve our objective? Depending on your relationship with the group of the stakeholders you may have to be diplomatic as to how you pose the question.

Let’s work through an example. A project aims at providing insight into the inventory stored in many warehouses. The goal is to keep the inventory as low as possible while providing quick response to product deman…

Conceptual Integrity

It’s a well known fact that deciding what exactly to build is the hardest part of software development. So how does one deal with complexity and uncertainly? Sanity is retained and complexity managed by maintaining conceptual integrity in your solution. This goes beyond the conceptual integrity of the architecture, but the conceptual integrity of a solution.

As an architect who will start working from a set of initial requirements (and later work with the requirements management team to refine requirements) you need to understand why a business problem is being presented in a given way and why it’s being solved in a given way. The business problem and the conceptual solution need to be rational and need make sense as a whole. It’s not necessary, moreover – counterproductive, to have details at this level, but having a conceptual integrity of a solution before investing heavily into architecture design and analysis is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectur…