Stephan Schwab

A blog post on Microsoft’s Developers Network (MSDN) caught my attention. I found it via InfoQ’s article What is an Architect anyway?.

My own post about the topic was titled The architect role in Agile Development and appeared on my company’s blog. In it I was saying that there is no need for an architect in an agile team, but it makes sense to have a coach available. Now the members of the Microsoft Architecture Strategy Team propose three different architect roles in their own post:

DiegumZone in Software Architecture: Past, Present and Future:

What is exactly software architecture? Do we really need it? Why have we only recently been discussing it? Is there suddenly a contagious fever about software architecture infecting those who claim to be architects? Who are they actually: gurus, just senior developers, or maybe smooth-talkers?

[...]

Emerging Architect Roles

The considerations of economical changes like globalization and technological achievements like the Internet’s impact on the digital economy, pressed for formalizing software architecture as a discipline.

Although there is not yet a definite agreement in the distinct roles, we can sketch three major personas:

• Infrastructure Architect. These define the platform and other environments (hardware, basic software) to provide for business applications’ high availability. They must also work with developers to define mechanisms and standards that allow applications to achieve the security, reliability, manageability, transparency, and policy compliance essential to the modern business. It’s expected that the natural evolution of a senior IT professional is an Infrastructure Architect.
• Solutions Architect. These are responsible for the design of one or more applications or services within an organization, usually within the scope of a division (and for that reason also known as Application Architect). Examples of such applications are: Internet banking, companywide knowledge sharing portal, and distributed point of sales applications. A senior developer is a good candidate to become Solutions Architect.
• Enterprise Architect. Their job is to keep the business and its IT systems in alignment. They strive to maximize the return on IT investment by making sure that IT spending is prioritized towards business opportunity, and by optimizing the impact of investments across the organization’s portfolios of services, resources, projects, and processes. They must be a bridge between business leaders, development, and operations to ensure that mutual understanding is achieved, goals are realistic, and expectations are properly managed. Enterprise Architecture is about the big picture — how people and technology work together to produce world-class, long-term results. For that reason, this persona is also referred as Strategic Architect. What is expected is that a Solutions Architect or Infrastructure Architect becomes Enterprise Architect.

These job descriptions, essentially that’s what it is, sound like calling for another manager role. It awfully sounds like creating unchangeable rules and mandating platforms and technologies from a defined set of vendors. Let’s look at these job descriptions in more detail.

Infrastructure Architect.

The proposal calls for a senior IT professional to evolve into an Infrastructure Architect. It doesn’t mention a developer who can evolve into that role. So what is an “IT professional”? To me that sounds like someone from the corporate MIS department who has been installing and maintaining desktops, servers and networks with lots of help from the vendors. Those who work in MIS department are smart folks. But in my experience their view is limited to an experienced user’s view. They usually don’t have time to fully understand networking or operating systems concepts. They have to follow the manual and best practice articles. To me, given that my job is to develop a software, such a senior IT professional would be a great source of input to learn more about the technical difficulties the organization faced in the past. But I would not put such a person in a position to define implementation details for the developers. The risk is too high that in the end it will be a decision pro or contra a certain vendor’s platform (e.g. Windows vs. Unix) and not something that can be considered architecture.

Instead it’s the job of a developer – we are not talking about programmers who simply implement a specification – to be well versed in questions of security, reliability, manageability, transparency, and policy compliance.

Solutions Architect.

To me the design of applications is not something that a single person might be able to accomplish. Instead it’s a process comprised of a dialog with the stakeholders to learn their business, their ideas, and their requirements in combination with a team of experienced developers creating software in iterations and actively proposing solutions. What the Microsoft team writes sounds more like someone who creates Product Requirements Documents, UML diagrams or another kind of formal instructions for the implementers.

Enterprise Architect.

In my opinion that Enterprise Architect simply should be the CTO of the company. A large organization needs someone providing oversight to all the different projects going on. Not to mandate certain technologies or to prefer a certain vendor, but instead to make sure everything that gets deployed can interoperate with each-other. This person should be able to leverage the specialized knowledge of technology consultants without following a single one blindly. His job is to avoid vendor lock-in and silos, but not to limit the use of anything upfront.

This post is in response to a blog comment I received.

Henry Johns in his comment to Silicon Valley is looking to do business in Latin America:
The challenge of getting South and Central America competitive in offshore outsourcing is two fold. Available talent pool, and available talent pool with English language proficiency. It is easy to staff a project team of 50 developers in India. Try doing that in Panama or even Brazil without leveraging English speaking project managers or team leaders with Portuguese speaking developers. Sounds like a plan except many of the developers will not be able to read the project support documents.

The language barrier certainly exists in all places and India has been lucky to have adopted English as an intermediary language even amongst their own citizens. Being fluent in English is definetely their primary competetive advantage. Still I believe it all depends on the type of work to be done and who the clients are.

If the goal is to extend a company’s workforce, then the offshore workers need to speak the same language as their onshore colleagues. English helps Indians with the American market. But their advantage diminishes in Europe, as not all and every European speaks English well enough or feels comfortable working in English for that to work out.

I cannot speak for businesses like call centers, help desks, systems support, etc. My topic is software development. Based on experiences with my clients my opinion is teams that were assembled ad-doc by recruiters or other staffing organizations usually don’t work well. As in sports a good team needs some time to train together and learn how everybody ticks. Nobody in their right mind would hire a group of guys who have never played together and expect them to win the World Cup. It doesn’t matter whether all players are superstars within their respective home teams. Still in software development exactly that is done and then people wonder why it doesn’t work and projects fail.

Not everybody on a development team needs to be able to discuss details directly with the customer. But everybody should be listening to what the customer has to say. Not necessarily has this to happen in a classic meeting or conference call in real-time. In my opinion customer feedback is best processed after it has been written down and be read several times regardless whether it’s been written in one’s mother tongue or a foreign language. And not only is it easier for humans to truly understand the meaning of written text, it can also be machine translated. It’s amazing how good Google’s English/Spanish machine translation is. I expect it to work even better with more formal content than newspaper articles or blog posts. What is usually missing is a tool that helps the English speaking stakeholders and the Spanish speaking developers to communicate effectively.

My company is working on an agile project management tool called Savila. We are currently investigating how to integrate machine translation for user stories.

Henry Johns adds in his blog comment:

Many countries in Latin America could do the same thing as Microsoft is doing in Canada. Bring in foreign high tech workers to jump start small offshore outsourcing businesses. I get resumes from professionals in India often who want me to sponsor them with an H1b work visa in the U.S. Why not bring them to some place like Panama?

This refers to Microsoft’s move to open a development center in the greater Vancouver, Canada, area – just on the other side of the US/Canadian border across from Seattle where Microsoft’s headquarters are.

That’s certainly an interesting idea. But the language barrier still exists and it is probably even higher. Actually there is a group of Indians teaching computer topics here in Panama. They are employees of the Indian outsourcing and consulting company Tata and their presence is kind of a gift from the Indian government to the government of Panama. All classes are given in English and I have some doubts whether that’s entirely useful. For someone without years of speaking a foreign language it’s certainly easier to receive the initial training in the language they’ve grown up with. It’s hard to learn two things at the same time and even harder, if thing A is the condition for mastering thing B.

What indeed might make sense is to offer the English speaking Indians a place where it’s easier to immigrate to than the US and still be closer to the US than India. Certainly a better idea than to anchor a ship off the coast of California.

Can’t agree more: A Guide to Hiring Programmers: The High Cost of Low Quality