Ilias Tsagklis

About Ilias Tsagklis

Ilias Tsagklis is a senior software engineer working in the telecom domain. He is an applications developer in a wide variety of applications/services. Ilias is co-founder and Executive Editor at Java Code Geeks.

5′ on IT-Architecture: the modern software architect

Before I start writing about this let me adjust something right at the beginning:

Yes of course, there is the role of a ‘software architect’ in any non-trivial software development project. Even in times of agile projects, dynamic markets and vague terms like ‘emergence’. The simple reason for that is that emergence and democracy in teams only work within constraints. Though, it’s not always clever to assign somebody the role explicitly. In an ideal world one developer in that team evolves into the architecture role.

When I started working as an IT professional at a *big* american software & IT consulting company I spent around five years with programming. After that time I got my first architecture job on a big project at a german automotive manufacturer. My main responsibility was to design the solution, advice developers, project managers and clients in doing things and to organize the development process. I wrote many documents, but I didn’t code anymore. The result was that I lost expertise in my core business: programming. So after a while my assessments and gut instinct got worse, which results in worse decisions. As a sideeffect of generic (vague) talking it got harder to gain acceptance by the developers, project managers or clients. When I realized all that I decided to do more development again. Today, I am doing architecture for 10 years. I am developing code in the IDE of my choice at least 20-30% of my time.

Avtivity profile

Whilst programming is a necessary activity, there is a whole bunch of activities that are sufficient to be successful as an architect. Doing architecture is a lot about collaboration, evaluating alternatives objectively (neutral and fair-minded) and about decision making. It’s a lot about communication, dealing with other individuals that almost always have their own opinions. Further more it’s a lot about forming teams and designing the ideal development process around those teams to solve the concrete problem. Last not least it’s about designing (structuring) the solution in a way that all functional and non-functional requirements are well covered. You can do all that more or less without super actual technical knowledge. But I believe an architect can do better if he/she has technical expertise gathered by day-to-day coding business. In the long run you cannot be a technical architect without sufficient coding practice.

 Figure 1: Activities of the software architect


Solving tradeoffs

When I worked as an architect I often found myself in difficult tradeoff situations. That is, I wanted to improve one quality attribute, but to achieve that I needed to downgrade another. Here is a simple but very common example: its often desireable to have a highly changeable system with best possible performance. However, these two attributes – performance and changeability – typically correlate negatively, when you want to increase changeability you often loose efficiency. Doing architecture often means to find the golden mean between competing system qualities – it means choosing the right alternative that represents the best compromise. It’s about finding the balance between system qualities and the environmental factors of that system (e.g. steakholders, requirements). The operations manager will focus on the efficiency of a new system, while the development manager will argue that it’s important to have a changeable system that generates little maintenance costs. The client wants to have a new system with the highest degree of business process automation as possible. These situations consume a reasonalbe amount of time and energy.

Sharing knowledge and communication

Another superior important activity: sharing knowledge in a team of technical experts and other steakholders. The core problem of software development is to transform fuzzy knowledge of domain experts into merciless logical machine code of silly computers that only understand two digits: 0 and 1. This is a long way through the venturesome and endless jungle of human misunderstandings! Therefore, architects communicate a lot. They use models to do that. Models serve as a mapping mechanism between human brains and computers. The set of problems that can arise during the knowledge-to-binary transformation is very diverse. It’s impossible that every team member knows all of them. That’s another reason why sharing knowledge in a team is so superior important.

Nobody is perfect!

Needless to say that nobody is perfect. Every team is different and so is every concrete situation. So in one situation one may be the right architect for the team while in other team set-ups that person doesn’t fit. An architect can also have different strengths. I know architects that communicate and socialize very well but don’t do so good in designing solutions or organizing the development process. Although they don’t master each individual skill, they’re all good architects. The common ground is that they were all down-to-earth developers.

Reference: 5′ on IT-Architecture: the modern software architect from our JCG partner Niklas.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

One Response to "5′ on IT-Architecture: the modern software architect"

  1. Stakeholders is misspelled in the article .

Leave a Reply


− 4 = three



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.