Thursday, August 13, 2009

Conway's law

Conway's law: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Wednesday, August 12, 2009

Take control

Being a firebrand architect at times requires assuming control of a situation even if you are not the primary owner of a project or an initiative. It often means taking on more responsibility than you expect just so that you can do your job later.

Imagine a coordination teleconference between twenty people from over a dozen different IT and business functions. The objective is simple: move a server from one domain onto another without breaking the existing solution on that server. Everyone on the call plays a role and an agenda unifies the participants for the duration of an hour. However no progress takes place - the current executive owner of the server gave a green light for migration as long as his technical team is comfortable. Yet the technical team (two developers) lack the enterprise wide knowledge to fully explain what services, data, and support they need and how their solution has been setup. In this case a COTS based application reaches out to various data sources and allows end users to analyze the data and create reports.

Mild chaos emerges.

As a firebrand architect you need to understand your objectives (in this case you would use a portion of the target server as a resource for another project) and assume control of the situation. Since you'll be sharing the resource with a team that lacks the technical know-how to make a migration, it's to your advantage to offer them help for "free" in order to get assurance that the target resource will be setup and configured right.

To do this, establish your credibility. Demonstrate to the group that you understand the big picture. Volunteer to help and follow through. This requires working with the owners of the application to reconstruct the architecture of the existing solution and understand the existing interfaces, the enterprise resources, and future needs of the project. Research and evaluate migration approaches. Understand the resources in the new domain to ensure that all needs of the same server and its application are met. Then lead the coordinate the migration effort.

Taking control will consume your time, but in the end you'll know that your target environment will address your needs. Just as importantly during this exercise you'll build a relationship with the colleagues who are sharing the server with you. And that's a great way to start cooperation when shared resources are involved.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Thursday, August 06, 2009

Specialization

Whether we want it or not, we, as software (solution) architects have to specialize in a bounded business domain and a bounded array of technologies. The required depth of knowledge depends on the type of architecture work you do.

While finding the "golden balance" is an obvious observation, a helpful reminder for you is to review your "golden balance" once every quarter and don't be afraid to re-define what you mean by your balance. It's natural for people to change - some become more specialized and technical, others pull up and specialize in a macro view. If you move a lot between low level and high level architecture you'll experience "turbulence" - and that may be OK if that's how you define your balance.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Tuesday, August 04, 2009

Microsoft Technology Center in Silicon Valley

Having worked for two startups I was not surprised to see glass enclosed server room positioned prominently to the side of the main work area. After all this a customer centric facility where select Microsoft customers are invited to spend time with the best and the brightest Microsoft hands-on technologists.

But it was not the stacks of the latest hardware with its neatly tucked cables in dust free racks that impressed me. Not even the myriad gizmos such as a touch screen HP's desktop and a Microsoft Surface. What impressed me are the people who worked at the Microsoft Technology Center in Silicon Valley on my recent trip in July 2009.

For the duration of the weeklong stay the hosts ensured that all our activities stayed within the scope of the business problem we defined on day one. And that's the key. The hosts took time to understand the business and concrete problems in the context of an end-to-end scenario. They adapted quickly to our team's terminology and collectively the whole team defined the agenda and measureable goals for the week.

When iteratively defining architecture for a solution it's imperative to define a core scenario that represents the essence of the solution. Structure your scenario in such way that you can bolt-on complexity as discussion progresses. For a proof of concept solution that we built at Microsoft Labs we were able to see how various degrees of complexity could be addressed as solution concept evolved. These "complexities" can be classified as either constraints, functional requirements, or quality attributes.

In our case the goal was to capture the overall wholeness of the solution at the expense of not implementing all organization's constraints and all desired quality attributes. However seeing all segments of a solution in action as part of an end-to-end scenario is a huge achievement itself. And that's worth the trip to a Microsoft Technology Center (in Silicon Valley).

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Monday, August 03, 2009

Seeing The Big Picture

In any organization - large or small - we make assumptions about new people who join a project or an initiative. First impressions matter, and while first bad impressions can be reversed over time, it's better to start on the right foot. While this is not news to you, it's important to remember this. This is especially important for a person who aims to act like a Firebrand Architect® since such behavior and action may be perceived as negative and derailing.

This set of reminders may help you:
- Listen to understand
- Understand the other person's point of view
- Learn what others are doing and why - conduct preliminary independent research
- Understand different roles colleagues play. Then understand your role
- Ask intelligent questions - advance conversation with your questions
- Speak slowly - this will allow you to formulate your ideas more clearly
- When replying pause to allow others to respond before switching topics. If you hear (or feel) that others are trying to speak when they think you've reached the end - stop speaking.

The behavior and actions above may not be automatic for every individual, but every person is programmed with these behaviors. Execution is a matter of desire and a healthy perspective on the big picture.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com
Add this blog to your RSS / blog reader.

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...