Enterprise Architecture

Part 12. Regular adaptation to changing circumstances

With self-organising teams, this is a reality at the development level. However, what about the enterprise?

Agility is a big buzzword at the moment and in a lot of cases, quite rightly too. However, an…

Part 11. Self-organizing teams

TOGAF, as mentioned already, facilitates the identification of capabilities at different levels. This can include the functions of QA, Business Analysis, Development, Architecture, Test, Technical Infrastructure and the like within the IT capability. As long as the vision of…

Part 9. Continuous attention to technical excellence and good design, and… 10. Simplicity

In truth, I found this sits at a level above the understanding and capability of almost all contemporary agile developers on the market. If they understood it, they would…

Part 8. Projects are built around motivated individuals, who should be trusted

A project may contain sub-projects. Each sub-project is in itself a project to deliver a capability (aka a piece of functionality) in accordance with success criteria which includes all…

Part 7. Face-to-face conversation is the best form of communication (co-location)

In a previous blog, I indicated why this principle is highly deficient when applied to anyone outside the immediate development team. Additionally, there is a strict reluctance from both…

Part 6. Close, daily co-operation between business people and developers

Remember, in TOGAF everything and everyone is a capability at a high level. Looking down from a strategic architecture, through segmented architecture at the capabilities, we see that IT is a capability…

Part 5. Sustainable development, able to maintain a constant pace

TOGAF maintains the status quo and doesn’t explicitly address tempo in the standard. Again, it is more interested in the delivery of capabilities to the business and it is the programme management office’s…

Part 4. Working software is the principal measure of progress

I personally have a problem with this definition anyway. ‘Working software’ as the agile developers of today know it, is necessary but not sufficient. If the definition of working software is to include ‘fit for purpose’…

Part 3. Working software is delivered frequently (weeks rather than months)

This is the same as stating that an organisation needs to be able to change direction quickly and change its internal operation to match. SOA platforms deliver this using orchestration processes where…

Part 2. Welcome changing requirements, even late in development

Change is good from TOGAF’s perspective. TOGAF encourages ’Just Enough’ design, as it is under no illusions that the requirements (fed by the organisation’s environment) will change during the lifetime of the larger…