As a software architect, you must play the role of client advocate. Your primary mission is the see your client’s vision through to fruition. A project manager cannot play the role of client advocate, because they are concerned about a schedule and budget. A software engineer cannot play the role of client advocate, because they are concerned about how the software will work, not how the people that will use the software will work. A software builder cannot play the role of client advocate, because they are concerned about coding.
As a software architect, you must have you feet planted firmly in both worlds. One foot must rest in the client’s world of business problems and opportunities. The other foot must rest in the builder’s world of software problems and opportunities. You must either be a business subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. You must either be a software subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. Perhaps you must be some degree of all of these. Remember: you are one that the client is depending one to see the bigger picture.
With my feet firmly planted in both worlds: business and software, taking on the role of client advocate and software builder to bring larger and larger software components together to create a harmonious whole, I've never had a problem getting work done with the technology at hand; whether the hardware is main-frame, mini-computer, or microprocessor; whether the operating system is MVS, UNIX, Linux, or Windows; or whether the programming language is procedural or object-oriented.
I've only encountered problems with people coming to a consensus of what needed to be done in the first place. So concentrate on getting a consensus to start and everything else will fall into place.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page