Surviving all the ways the software architect’s role has changed over the last 18 years comes down to two things for Constantin Mihai—staying curious and keeping the door to his childhood propped open just a bit.
“I have always had a profound respect for Microsoft as the most relevant software company in the world, a company that has always understood software development and software developers. This respect brought me here,” says Mihai, a software engineering lead in Core Services Engineering and Operations (CSEO). “At Microsoft, I let my inner child drive my curiosity.”
That kid inside has kept him fired up as his career as a software engineer and architect and leader has transformed again and again—he has changed roles nine times during his 18 years at the company.
He tells his team members and anyone who will listen to continuously evolve the way they work to stay relevant. Adopt modern engineering principles. Embrace moving to the cloud and the new ways of working that come with that. Adjust personally by owning your work from end-to-end, by walking in your customer’s shoes, by letting go of legacy tools and processes that are no longer needed, and by building on and supporting the work of fellow employees.
Mihai joined many teams and product groups over the years, learning new architectural styles and engineering practices and methodologies in groups like Bing, Microsoft Research and Microsoft Azure along the way. He said having an open mind and flexibility has led him to his current role leading teams of engineers who support the company’s Finance and Business Intelligence teams. Though he’s not officially an architect anymore, he and his teams embrace owning that role as part of owning the engineering process from end-to-end, and it’s something that Mihai has done under various job titles throughout his career.
Architecting the path of a software architect
When Mihai started out, Microsoft was still building software that would take two to three years to build.
“During those early years, the common denominator was long waterfall development cycles,” he says. “You would spend three to four months on design, three to four months on development, three to four months on integration, and three to four months testing and stabilizing. And then you would do it all again.”
Asking customers what they wanted?
It happened, but not enough.
“We had select partners who gave us feedback on our alphas and betas, but that was about it,” he says. “We would use this limited feedback to make major changes. This offered a skewed and limited view of our work.”
Architecture as a distinct discipline was elusive at the time, and when it did happen, it was not collaborative.
“The act of architecting complex systems and frameworks was very much present,” Mihai says. “It had all the attributes of an ivory tower—it was activity performed in isolation by some of the most senior product team members, usually software developers and occasionally technical program managers.”
Over time, architect became a formal role you could pursue, and many did. “At some point, there was an inflation in the number of architects around the company,” he says. “I remember a certain product group where we had an entire floor occupied only by architects who were providing product direction with very little interaction and feedback from the vast majority of professionals within the group, hence the ivory tower.”
A lot of the work was performed in silos.
“Conway’s Law was very prevalent at the time,” Mihai says. “The architecture was usually a projection of the organizational structure we were using at Microsoft at the time. You used to have a team specialized in UI development, another one covering backend/API development, a data layer team, another one for business intelligence, etc. Test teams had their own structure, too.”
The various layers of the architecture used to mimic the structure of teams very closely.
“If you worked on UI concerns of the system, you had little opportunity to influence the shape of the APIs consumed until later in the game,” Mihai says. “Teams usually started a project by dedicating a lot of time to prototyping new product ideas and working on comprehensive design documents. Other teams used to learn about your component’s direction by studying your design and test documentation produced towards the end of the design phase of a project. There was not a lot of opportunity to cross-fertilize our product ideas.”
Things changed profoundly over the years, some of which was spurred by the company adopting a startup culture in research labs that started popping up around the company. “I had the privilege of being part of such a group called Live Labs,” he says. “The startup culture brought in the agility required to challenge software development processes in place.”
Enter the cloud and modern engineering practices
Moving to the cloud and adopting agile engineering methodologies are among the factors driving the transformation of the architect’s role in CSEO.
“The introduction of agile practices like Scrum, Kanban or even Nexus provide a completely different software development rhythm that allow us to fail faster, while continuously evolving their understanding of product design and optimizing system architecture,” Mihai says.
Continuous Integration and Continuous Delivery/Deployment (CI/CD) as extensions of agile are streamlining the company’s software development pipelines up to the point where product components are integrated, tested and shipped on a schedule that would have been hard to imagine 10 to 15 years ago. “Nowadays, we are talking about weekly or even daily releases for all our externally or internally facing cloud products,” he says.
It amounts to turning Conway’s Law upside down.
“More and more, the Inverted Conway Maneuver is shaping our organizational structures for the sake of turning the bad traits of Conway’s Law into a positive outcome for our projects,” Mihai says. “This way, the structure of our teams becomes a projection of the architecture we are aiming for.”
Mihai says a big part of software architecture is about controlling the boundaries and what happens at the level of system boundaries, component boundaries, boundaries between team, and architect responsibilities. “What happens inside such a boundary is mostly design, not to be mistaken for architecture,” Mihai says. “The architect’s job is to influence the design, development and integration of many software components, usually delivered by multiple and sometimes loosely connected teams, towards a highly coherent and cohesive state, an optimal one.”
Every application or experience that CSEO builds comes with its own technological landscape, which makes it hard to pin down what makes a good architect. “They need to be proficient at distributed computing, the art of scalability, concurrency and parallelism, workflow modeling and execution, pattern languages and, of course, they must have intimate knowledge of all Azure specific resources,” Mihai says.
Soft skills are equally important, including communication, presentation, and negotiation. Architects also must be avid learners. “It helps to be curious about many literacies, including systems theory, constraints theory, decision theory, complexity theory, game theory, and complex project management,” he says.
All engineers in CSEO and across Microsoft must take on the role of architect—they need to own the end-to-end development of the tool or processes that they are building. There is still a need for high level architects to connect the dots between different teams and groups, but most of the work is now done in the trenches.
“Most of the architectural work is performed by the teams themselves,” Mihai says. “This kind of grassroot empowerment helps the teams build the architectural muscle that allows us to scale the decision-making processes across multiple teams and projects.”
Charting a new path for Microsoft
Mihai sees many opportunities for engineers who lean toward architecting to influence how Microsoft continues to transform.
“Most of our opportunities will be in the realm of further optimizing our cloud-based enterprise applications,” he says.
He rattles off cost optimization, trimming out redundancy, improving on-the-fly provisioning, and the opportunity to flight multiple product behaviors in production environments as just a few upcoming in-the-trenches opportunities.
The push to an Intelligent Cloud is another opportunity.
“No exaggeration here,” he says. “The options that we have in terms of increasing the level of intelligence of our applications and workflows, the self-healing system behaviors that can be added, and the conversational aspects that can be built into our apps are huge—they are only limited by our imagination and creativity.”
Automation is also rife with opportunity.
“We should not limit ourselves at automating existing processes but extend the purpose of automation to the reasoning around these processes. The ultimate goal of our cloud endeavors should not be their full automation only, but also the seamless integration of reasoning and inferencing into our cloud application fabric.”
A massive increase in data and the ability for agents to reason over it will create a new class of opportunity for companies like Microsoft to learn, respond and grow. “This is hinting towards an even bigger wave of transformations on the horizon,” he says.
Mihai loves how CSEO’s leadership team is bringing this transformation to the company’s IT organization, a move that is in line with the larger company and product group engineering teams.
“Our organization can easily be considered one of the champions of transformation,” he says. “Turning a ship so big around, in such a brief period, and determining a change from waterfall processes to agile processes on such a scale is a wonderful accomplishment.”
Personally, Mihai has transformed from architecting and building solutions to crafting, mentoring, and coaching dev teams.
He looks forward to helping CSEO continue to reinvent itself.
“The act of the transformation, in itself, appeals to me because it is the best proof of vitality both for the business of Microsoft and for its people,” he says. “Change or transformation does not represent an option but a condition of success. As Benjamin Franklin said, when we are finished changing, we are finished.”