Showing posts from October, 2009

adding complexity to reduce complexity

In a recent Software Engineering radio episode Markus Voelter in his interview with a guest described complexity as energy. More specifically he talked about the law of conservation of energy (energy cannot be created nor destroyed, it can only be transformed). The topic of complexity can be viewed similarly.

By addressing some nuance of complexity in a project (e.g. growth of a team) we're applying tactics (e.g. hire a manager) that may solve the issue of coordination, but introduce the issue of bureaucracy.

We have come to accept these unattended consequences (or collateral damage) as a fact of life, but it's good to remind ourselves to question why we choose one tactic over another. Some of our "trivial" decisions are binding with no undo button.

Constantin K.
Firebrand Architect®

See the ecosystem, not the forrest

As a software architect one must see a forest and not just trees. As a Firebrand Architect® one must see an ecosystem and not just the forest.

Constantin K.
Firebrand Architect®

Architecting Windows 7

"To Rebuild Windows, Microsoft Razed Walls " is the title of an article in the October 20th 2009 edition of the Wall Street Journal.

There is something interesting about Microsoft's software development approach taken for Windows 7.

The article attributes the perceived initial success of Windows 7 to a different, more humble, approach taken by Microsoft and the Windows 7 team. While the quality of the operating system is yet to be determined by the real world tests it appears that the design and execution of the product was different.

"A key problem was that the Windows team had evolved into a rigid set of silos—each responsible for specific technical features—that didn't share their plans widely. The programming code each created might work fine on its own, but cause technical problems when integrated with code created by others."

This article exert contains a key observation. Operating system development can be viewed as a set of semi-independent silos unit…

What kind of leader are you?

An architect role is a leadership role - that's a fact. Your leadership style and your capability to lead will enable or cripple your team.

There are many leadership gurus with thousands of books on the subject. For the purpose of this post and to keep things simple I'm using John C. Maxwell's five levels of leadership strucutre. I've been to his lecture and I like the simplicity of his approach. John's repertoire of books is significant (, but at its core the following structure stands.

Level 1. People follow you because they have to.
Level 2. People follow you because they want to.
Level 3. People follow you because of what you have done for the organization.
Level 4. People follow you because of what they have done for them.
Level 5. People follow you because of who you are and what you represent.

The first level is self explanatory.
At the second level your leadership depends on the relationships you build with the people. At this level you're conne…

PDC 2009

If you're on the Microsoft bandwagon, then PDC 2009 is for you.

Constantin K.
Firebrand Architect®

You, as an architect, must take the initiative

Simply by having an "architect" word in your title or role description automatically puts a heavy burden on you. Automatically people will assume, and rightfully so, that you have the responsibility of gathering and synthesizing information and making early design decisions. Your colleagues and stakeholders will expect guidance from you - well before and after the official software design phase commences.

As an architect you should be very well aware that you're under a spot light at all times. Nobody will ever tell you that the right time has come to start architecting. If someone has to tell you that now is the right time to start architecting it means that you're not paying attention. There are, of course, times when it appears that no action is required. For example, requirements are too fluid and insufficient to start designing, or a business case for a solution has not yet been well defined, or perhaps the funding has not yet been approved. The times of uncertai…

Interviewing future leaders at Carnegie Mellon - Heinz College graduate students

It's truly inspiring to speak with young graduate students who passionately feel about positively changing the world. This week I was asked to join a small team interviewing graduate students (Carnegie Mellon - Heinz College) who are seeking employment in late winter or late spring to put their degree to a good use.

The most exciting part of the interview was seeing how most students in my group were able to discuss concrete problems from an end-to-end perspective. Here is a general observation about the future leaders:
- they can effectively organize and leverage team members' time and skills; they are have a disciplined and patient approach for deciding who would lead and how the tasks should be distributed
- they continue to learn and care a whole lot about learning opportunities their employer offers
- they are open to new ideas and observations; change is not a distant concept, it's a way of life
- they are data driven at all the right places; they understand the value of …

You can't rely on your knowledge of patterns alone to architect

Design patterns are used for solving a specific known (routine) problems using a prescribed approach. For architects the patterns are the building blocks of the systems we create. An architects needs to have a working knowledge of a diverse library of patterns spawning various levels of granularity and applicability relevant to his or her domain.

It's important to note that all patterns fit somewhere on the spectrum of design decisions. All patterns can either be refined by lower granularity design patterns or rolled-up into larger patterns. However there are exceptions to these rules impacted by strategic vision and availability of resources (constraints). This is what makes architecting fun.

Constantin K.
Firebrand Architect®

Example of a solution not fit for purpose

Five years ago I architected and (with a small team) implemented a COTS centric solution (Microsoft and ProSight technologies). The design process was supported by clients and all phases of SDLC were executed well. Architecturally significant decisions were made based on factual findings. For example, after an evaluation of enterprise environment we concluded that the necessary bandwidth required by COTS software wasn't available and a decision was made to allow select user groups to access software directly on a server via a remote desktop connection. Other user groups would use web interface for simpler tasks. We estimated the number of users, application load cycles, data call spikes, etc.

In the end we crafted a seven sever solution with load balanced web front ends, separate logic server for data crunching, and a set of very powerful database servers (in 2005 fully loaded HP ProLiant 570 were the best of breed).

At UAT the solution surpassed technical and usability expectations…

What exactly is "fit for purpose"

Firebrand Architect® adopted the "software fit for purpose"™ mantra for a very good reason. It's the architect's job to make and bear responsibility for decisions that can make or break a software solution. Of course an architect is not the only factor in the success of a solution, but clearly early design (and approach) decisions come with high cost.

Deciding on what's fit and what's not fit, and how to reach the right balance, is a subjective and difficult question to answer. This is why software architecture (and various other flavors of IT architecture) will always be part science and part art. This is why there will be more and more architecture specialists (e.g. security architect, performance architect) over time as complexity of software solutions (or rather system of systems) grows. And this is why architects of all flavors need to have a well rounded understanding of the operating environment - including human aspects.

In order to convince oneself tha…

Software Engineering education for your clients and customers

This is not a "how to" post, but a reminder to build in time for client and customer education on software engineering. There is only one person in this world that thinks exactly like you, and that's you. Everyone else around you, even your long term colleagues, have a different perception of problem, solution, and approach even if you work well them.

This observation calls for two actions:
1. Build time (directly or indirectly) into your project to educate your clients and customers on the discipline of software engineering and software architecture. You'll have to spend time convincing them that a disciplined approach to creating software is not a choice, but the way of life.
2. Create a mini curriculum, or at least talking points, ahead of your engagements with clients and customers. You need to be proactive in your education sessions and they always should be done in the context of a specific business problem or a solution you're working on.

If a client or a cust…

Writing down solution concept - a practical quick start guide

As an architect you’ve been tasked to come up with a business and technology solution. Where do you start? You probably have a lot of ideas and concepts in your mind. The best way to get started is to offload your ideas and concepts into a list – or better yet on paper or whiteboard (or Visio). As you dump ideas down you’ll be tempted to expand and link the concepts right away, but first concentrate on writing everything down.

The next step is to create a “back of a napkin” business perspective of your solution. What are the key components and functions? Perhaps a shopping cart, an inventory management thingie, a brain to pull it all together, and a payment processing element. Use whatever media you’re most comfortable to quickly sketch a business architectural cartoon. Show how things are linked.
Allocate all elements from your list at this stage.

The disciplined part of you may be tempted to think about decomposition using proper architectural perspectives (static, dynamic, and physica…

Using consultants for big picture insight

Few software engineers and software architects have the privilege of being meaningfully involved in so many initiatives that they see the big picture of where the organization is going. This does not apply to all architects and all organizations, so this tip is for large organizations.

If your organization is using consultants to help on various projects you should consider tapping into their experiences for a big picture perspective. Yes, they will ask you to fund the time they spend gathering the data and creating a presentation, but the insight may be worth the time and money. It’s always very beneficial to have a third party provide feedback on the elements you don’t have time or ability to see.

Caveats: only work off the existing trust level. If there is no trust between you and a consulting group you won’t benefit from provided insight. Pay attention to the recommendations and the consultants’ line of work – they may be consciously or subconsciously selling you more work (and you …