Do I need to to follow formal methods to be a "real" Software Architect?

Question

I'm a programmer who has become a software architect through experience of what works in various situations, combined with an understanding of business. I suppose you could say I follow the Good enough architecture methodology.

Larger corporations have a very different view of what a software architect should be (I generally don't fit their definition!). The words IT Governance and TOGAF / Zachman usually crop up.

Do I need formal training on IT Governance? Do I really need to know specific architecture frameworks to be a software architect?

Edit: I know larger companies look for it (as I have mentioned), I'm asking if you can really be considered a software architect without following these formal methods. (this is not a question on whether software architect do/should exist!)

Edit 2: I'm an architect who is responsible for taking an idea (from a client or the business), finding out what they really want, and turning it into a product with a team. And yes, I do code.

Answer 1

If you want to work for the larger corporations then yes, you need those standards. In smaller organisations titles are extremely nebulous and what your organisation considers a Software Architect may be a different title elsewhere.

However, when you get up to Enterprise level you can be sure that the title is relatively consistent (there's still opinion out there) and that globally accepted IT standards are going to form a large part of the expectations. When you are dealing with an organisation with literally thousands of systems you have to ensure that anyone guiding the development of systems within that landscape is intimately familiar with the standards to which they have been built or toward which they are moving.

Answer 2

Are you a software architect creating software products or an IT architect responsible for mainly plugging things together? I think there's a very big divide and the frameworks apply mainly to the latter.

I think you could draw a spectrum from creative at one end and project manager at the other, with typical IT Enterprise architects being a long way towards the project manager end.

I always encourage people to study - reviewing things that might be seen as outside your domain is a great way to generate ideas. However, I'm sceptical about the value of the formal frameworks if your role is more on the creative side.

You might find Evaluating Software Architectures: Methods and Case Studies interesting.

If you want to avoid spending a fortune on books (even more so when you're as remote as Perth!) I recommend Safari, there are a few good architecture books on there:

• Beautiful Architecture
• Software Architecture: Foundations, Theory, and Practice (recommended by Roy Fielding, the inventor of REST)
• Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives

Answer 3

Update re:

I suspect smaller companies just don't need some of responsibilities (e.g. governance), they are an overhead of being a big company. – badbod99 10 hours ago

There isn't a need to be formal about it, but the underlying need is usually there. Personally I'm very practical about it, so I don't feel is so much about some recipe with fixed tasks, roles & docs, but more about understanding well what all those are solving and making sure those needs aren't being left unattended. Sometimes those go unchecked, and eventually become a major roadblock to the company

In fact that's a very good example you choose, IT governance. I'm sure you'll agree that the following is important regardless of the size of the company:

Information Technology Governance, IT Governance is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The rising interest in IT governance is partly due to compliance initiatives, for instance Sarbanes-Oxley in the USA and Basel II in Europe, but more so because of the need for greater accountability for decision-making around the use of IT in the best interest of all stakeholders.

A characteristic theme of IT governance discussions is that the IT capability is directly related to the investment choices taken by top management that have long term consequences for various stakeholders. The traditional involvement of board-level executives in IT issues was to defer all key decisions to the company's IT professionals. IT governance implies a system in which all stakeholders, including the board, executive management, customers, and staff have clear accountability for their respective responsibilities in the decision making processes affecting IT. This prevents IT or business leaders from independently making decisions about IT without retaining responsibility for their actions and the impact they have on supporting the achievement of strategic objectives. http://en.wikipedia.org/wiki/Information_technology_governance

How many times have you heard developers or infrastructure complaining about a senseless decision someone else at their company made, and they have no say in it? (also the other way around). At its simplest level the need is addressed by talking and listening about important decisions.

You are probably handling that need in your company, specially as you mentioned in a comment:

Architect for me is more about understanding the business/client requirements, pulling together a team to achieve a goal, and coming up with a technical solution with the help of the team. I can't think of one day I have spent drawing class diagrams!

---

Overall I'd say no, but be aware that there are different levels involved.

Its not the same driving an enterprise architecture, than it is doing the software architecture for specific projects. These roles are easily mixed at smaller companies, but sometimes part of the responsibilities involved are shifted to other people in the company.

If you are aiming to keep on software architecture in the context of specific projects on a larger company, then you are probably safe. But if you are intending to be involved at a higher level, then you should have a look at these methods to make sure you develop the skills to fulfill the different role.

Also note that its hard to know how what you are used to do, matches what the target enterprise have their architects do.

Answer 4

In many cases the the Good enough architecture methodology will be fine and the most cost effective.

However, there are situations where having a formal framework is usefull:

• You are a consultant doing architecture for clients. Then it is possible to explain to the customer what they will get.
• You are working on a very large project with many architects. Then it is important that everyone does things in the same way.
• You are in a large organization with many projects. Then it is important that all projects are documented in the same way.