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.
I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...
Great blog post by Agile Journeyman about Martin Fowler's Design Stamina Hypothesis & the Technical Debt Quadrant. Constantin K...
Agile processes give you an ability to do something faster. Often agile approaches give you an ability to deliver smaller chunks of software...
From the SEI podcast series: "We know from existing SEI work on attribute-driven design, Quality Attribute Workshops, and the Ar...