locked
Consulting vision of a role of a software architect in ISV RRS feed

  • General discussion

  • Hello everybody,

    A am preparing a vision of a role of a sofrware architect in my company. I have some ideas, but I want to consult them with you. I will start with describing background - my company.

    My company is an ISV. I employs about 150 developers writing code in C#. We develop sofware mostly for financial sector: banks and insurance companies. Most of applications are built for one customer only. When growing, my company defined roles of analysts (doing business and requirement analysis), team managers and developers. There is no role of an architect or a designer currently.

    In my opinion, classic role of a 'software architect' (as presented in ArchJournal 15 by Daniel Akenine) fits very well in my company. I see architect in ISV as a role with following 'soft' responsibilities for communication:

    * with management and customer representatives to create consistent vision of software system development
    * with analysts in creating reqiurements specification which is implementable (thanks to architect's technical insight)
    * with designers and developers by providing guidance how to desing and implement components of an application
    * with project managers to maintain high quality of produced software

    and a 'hard' responsibility for creating high-level desing which means decomposing system into logical components, designing interfaces between them and providing guidance about interaction type (synchronous, asynchronous) and desing style (e.g. dependency inversion).

    I am convinced that defining such a role in my organisation will help it build software which is:
    * more aligned to customer's business needs
    * have higher quality attributes, especially maintainability and flexibility

    What do you think about it?

    Szymon 
    Wednesday, November 19, 2008 2:34 PM

All replies

  • I find the architect role changes with each organisation.  In ISV's this sometimes changes from project to project.  Some teams need more guidance in one area than another.   

     

    In general I see the architect role comprising the following; Compliance, best practise, business alignment, coaching, leadership.

     

    Generally this fits with your vision.

     

    The difficult aspect of all this for an organisation that hasn't had anarchitect before is controlling and managing the change.

     

     

    Thursday, November 27, 2008 11:41 AM
  • There is a rule that every software developer knows: Design first, then develop - or you will be doing rework later on.

    The main reason software companies require architects, business analysts and non-developers is to ensure that the IT do rework as little as possible. All of the objectives that you wrote are fine, but keep in mind that software companies develop software not architectures. Your main job is to keep the developers running in a straight line directly to the company goal.

    Workflow software and BPM software companies require a lot of software architects (so if you are in the neighborhood...)

    Wednesday, January 7, 2009 9:25 PM
  • You're absolutely right.

    If you have 150 developers, and no architect for the software, you're likely to have a difficult time of things.

    Even if the architect is actually a senior developer, that person is going to be pulling together requirements, communicating a common goal, guiding and facilitating the vision of achieving such a goal.

    What will happen if you do not have such focus, is that you could potentially end up with 150 different versions of the exact same application, based on the 150 individual and differing views of each developer.

    An architect is a broader version of a designer, armed with more knowledge ranging from technical, or business knowledge, the architect, communicates a vision, validates it with the customer, and pulls together the design.
    What you appear to have is a number of people doing each of the roles that often make up the role of architect.  By that I mean BA, PM (possibly), team leaders.  An architect would probably be across all those roles, to be able to communicate and facilitate between each.  I could imagine that all those roles could still exist, as well as an architect, as that role would bring the other three together.  It could also be that the three roles could also be combined into one, but it is quite difficult particularly to be a good PM and an architect at the same time.

    I hope this helps,

    Martin.
    MCSD, MCTS. Please mark my post as helpful if you find the information good!
    Sunday, April 5, 2009 10:46 AM
  • There is a rule that every software developer knows: Design first, then develop - or you will be doing rework later on.

    The main reason software companies require architects, business analysts and non-developers is to ensure that the IT do rework as little as possible. All of the objectives that you wrote are fine, but keep in mind that software companies develop software not architectures. Your main job is to keep the developers running in a straight line directly to the company goal.

    Workflow software and BPM software companies require a lot of software architects (so if you are in the neighborhood...)


    You are absolutely right. You will find that it is too bad if you haven't put design at an important places because of some reason. We can't just ignore the design or refuse to attach importance on it.
    Wednesday, June 16, 2010 1:05 AM