Recently, when I was taking a session on 'Progressive Web App: Are we lagging behind?' in my current company, I wanted to introduce myself to a big gathering, who apparently knew me to a certain extend. Believe me, I gave a damn thought about it that I gave no intro, but just got started with the topic. However, I being an architect (precisely solution architect), that very thought gave me few sleepless nights, pondering what really an architect does. This write-up is all about a dilemma encountered on a daily basis in any architect's life in information technology.
Who is an architect? If you avoid technical jargon, architect is one who creates architecture. Ha! As per Aristotelian syllogism, this definition has a fallacy. Now, what is architecture? Since that is the point of discussion today, let me park the question, for now.
Based on the architecture one creates, he or she is categorised into any one of the three: software, solution or enterprise architect. To set proper context, I need to put forth my view of these three roles in an organisation. The easiest comparison I've seen is a graph with technology on x-axis and strategy on y-axis, where software or technical architect lies on the right-bottom most corner, enterprise architect on the left-top most corner, while the solution architect on the centre of the graph. Since there is no cause-effect relation between technology and strategy, which on what axis doesn't really matter here and therefore the position in an organisation too. However, as remuneration is directly proportional to the risk taken, it's right to place strategy on the y-axis and enterprise architect on top.
Image courtesy: LeanIX
For me, an enterprise architect creates the architecture that converts the organisational business strategies into technical terms. And the solution architect understands the strategy and design solution. The solution architecture can be one or more of these: application architecture on functional system, technology architecture on supporting systems, security architecture on authentication and authorisation of the solution, data architecture on data flow, integration architecture on how systems communicate each other, devops architecture on delivery and maintenance of the solution and so on. Software (or technical) architect, on the other side, creates technical architecture of the individual system with details like use cases, domain object model, component design and so forth. Enough of boring explanations!
In fact, the subject of our discussion is what architecture, in software sphere, means. Though it means a lot, generally it denotes the design documents created to help the implementation of the system. That means an architect is a 'documentalist'. But we know that's not true. An architect is involved in all phases of software development. Apart from the design documents, he or she is also responsible for the proof of concept and even prototype of the solution at the minimum.
At least in few cases, proof of concept becomes an alternative to design documents, of course based on the solution complexity. However, the dilemma is not about what to choose, but where to give emphasis. In other words, what does an architect deal mostly with? Documentation or Implementation? Again there is no definite answer. It all depends on the solution and the role one plays. However, everybody would have a soft corner towards one of them. Some people, like me, love the magic of codes compiled, whereas others do the beauty of the words diagrammed.
Obviously, both are important. So let the dilemma be there. You either choose one or mix both. The latter is preferred because falling into one of them (technology or strategy) makes your process complicated. If you emphasize on documentation, your software development becomes rigid (and may be useless later) and on the other hand, if you focus on implementation, you loose the scope (and may be unaccomplished later). Therefore, an equilibrium between them is required, not a dilemma of selection. I need to confess here that I've a leaning towards implementation (technology). In fact, documenting is an art and saves a lot of time. Let all master both with a right balance and take wise decisions. At the end of the day, it's all about getting the job done better!
Who is an architect? If you avoid technical jargon, architect is one who creates architecture. Ha! As per Aristotelian syllogism, this definition has a fallacy. Now, what is architecture? Since that is the point of discussion today, let me park the question, for now.
Based on the architecture one creates, he or she is categorised into any one of the three: software, solution or enterprise architect. To set proper context, I need to put forth my view of these three roles in an organisation. The easiest comparison I've seen is a graph with technology on x-axis and strategy on y-axis, where software or technical architect lies on the right-bottom most corner, enterprise architect on the left-top most corner, while the solution architect on the centre of the graph. Since there is no cause-effect relation between technology and strategy, which on what axis doesn't really matter here and therefore the position in an organisation too. However, as remuneration is directly proportional to the risk taken, it's right to place strategy on the y-axis and enterprise architect on top.
For me, an enterprise architect creates the architecture that converts the organisational business strategies into technical terms. And the solution architect understands the strategy and design solution. The solution architecture can be one or more of these: application architecture on functional system, technology architecture on supporting systems, security architecture on authentication and authorisation of the solution, data architecture on data flow, integration architecture on how systems communicate each other, devops architecture on delivery and maintenance of the solution and so on. Software (or technical) architect, on the other side, creates technical architecture of the individual system with details like use cases, domain object model, component design and so forth. Enough of boring explanations!
In fact, the subject of our discussion is what architecture, in software sphere, means. Though it means a lot, generally it denotes the design documents created to help the implementation of the system. That means an architect is a 'documentalist'. But we know that's not true. An architect is involved in all phases of software development. Apart from the design documents, he or she is also responsible for the proof of concept and even prototype of the solution at the minimum.
At least in few cases, proof of concept becomes an alternative to design documents, of course based on the solution complexity. However, the dilemma is not about what to choose, but where to give emphasis. In other words, what does an architect deal mostly with? Documentation or Implementation? Again there is no definite answer. It all depends on the solution and the role one plays. However, everybody would have a soft corner towards one of them. Some people, like me, love the magic of codes compiled, whereas others do the beauty of the words diagrammed.
Obviously, both are important. So let the dilemma be there. You either choose one or mix both. The latter is preferred because falling into one of them (technology or strategy) makes your process complicated. If you emphasize on documentation, your software development becomes rigid (and may be useless later) and on the other hand, if you focus on implementation, you loose the scope (and may be unaccomplished later). Therefore, an equilibrium between them is required, not a dilemma of selection. I need to confess here that I've a leaning towards implementation (technology). In fact, documenting is an art and saves a lot of time. Let all master both with a right balance and take wise decisions. At the end of the day, it's all about getting the job done better!
Very Relevant !! but the fact is nothing will move if we reach equilibrium !!
ReplyDelete