While working as an Architect for more than five years I had this question of which path should I proceed Tarchitect or an Marketect. Oh you must be thinking who they are. Software architects are categorized in to two groups Tarchitects and Marketects.A Tarchitect is a technical architect who will sink on technical path and do the technical architecture of a solution.
A Markitect is a business architect who do the business architecture of a solution.
People debate what is the correct path, for me inside every successful architect there should be an equally balanced Markitect and Tachitect. Why I say so, I hardly believe a technically savvy peace of code will not have any value without a person use it an solve a real world problem. This will be valid for both opensource and commercial software. In opensource it will increase the community and make that peace of code enhanced and in commercial software development it will make that peace of code an revenue generator.
So we have to make boundaries because architect cannot go and sell software as a Markitect and debug tiny little problems in a code as a tachitect. Architect should look at the problem by taking the business use-case and map it to the technical solution. To do that s/he should be aware of the fundamentals of both sides.
I will list down the key points to prove my argument
A Markitect is a business architect who do the business architecture of a solution.
People debate what is the correct path, for me inside every successful architect there should be an equally balanced Markitect and Tachitect. Why I say so, I hardly believe a technically savvy peace of code will not have any value without a person use it an solve a real world problem. This will be valid for both opensource and commercial software. In opensource it will increase the community and make that peace of code enhanced and in commercial software development it will make that peace of code an revenue generator.
So we have to make boundaries because architect cannot go and sell software as a Markitect and debug tiny little problems in a code as a tachitect. Architect should look at the problem by taking the business use-case and map it to the technical solution. To do that s/he should be aware of the fundamentals of both sides.
I will list down the key points to prove my argument
- A(T+M)chiTECT talk to the user and s/he knows what the user really wants (identify the actual use-case without having hypothetical scenarios)
- A(T+M)chiTECT talk to marketing and business development so they know business needs and marketing needs. (Identify the priorities)
- A(T+M)chiTECT talk to engineering teams and identify the technical incite of the products, codes.
- A(T+M)chiTECT build the awareness of the code by working with the relevant teams.
- A(T+M)chiTECT fill the gap between the technology and business.
- A(T+M)chiTECT build usable software and agile to the frequent changes of business/ market needs.
2 comments:
nice article asanka.. never knew there were two paths to being an architect... very informative... thx for this...
Dinuka
Thx, buddy lot more to come :) keep a eye.
Post a Comment