Gartner: Best and Worst EA and Application Architecture Practices

A Gartner webinar discusses the best and worst practices in enterprise and application architecture.

Betsy Burton, VP Distinguished Analyst, and Andy Kyte, VP & Gartner Fellow, hosted a webinar entitled Best and Worst Practices in Enterprise & Application Architecture (account required). Burton started the webinar by discussing ten best practices in enterprise architecture:

1. Charter Your EA Program focused on enterprise context – place EA in the overall business context; one cannot successfully run EA unless being aware of the existing business strategy.
2. Develop (and Execute) a Communications Plan – communicating back to the business, outlining the value of current EA developments.
3. Be Pragmatic (scope and iterate your efforts)
4. Treat Each Iteration Like a Project – EA is not a project, but each iteration can be treated as a project
5. Start With the Business Strategy and Obtain Business Sponsorship
6. Do the Future State Before the Current State – starting with the current state can lead to a “muddy” situation. It is better to start with a clear idea on where you want to go, what you want to do before investigating what’s the current status.
7. Don't Forget Governance – the enterprise architect is “facilitating, guiding, collaborating, and helping people work across the organization”
8. Set Up a Measurement Program (link to overall performance management) – measure the effectiveness of the EA program
9. Track EA Program Maturity and perceptions – people usually have different perceptions on their organization’s EA maturity, sometimes very different
10. Pay as Much Attention to Peoples Competencies as to Skills – technical expertise is not enough; communication abilities, among others, are essential

Burton also mentioned 13 worst EA practices, some of them being the reverse of some best practices:

1. No Link to Business Strategic Planning and Budget Process
2. Confusing "IT Architecture" With "Enterprise Architecture" – EA refers to the effort of evolving the entire business, while IT takes care of the information technology part of it.
3. Lack of Governance
4. Over-standardization
5. Focusing on the Art or Language of EA Rather Than Outcomes – the business outcomes should drive the entire EA efforts
6. Strict Following of EA Frameworks – 90% of enterprise architects use a mix of frameworks, and they don’t use them as cookbooks that need to be followed by the letter, which is good
7. "Ivory Tower" Approach
8. Lack of Communication and Feedback
9. Limiting the EA Team to IT Resources – it is recommended to have business people on the team
10. Lack of Performance Measures
11. Picking a Tool Before Understanding Your Business Needs – tools should support EA not drive EA. Burton recommends doing an EA iteration first, and one will know better what tool helps more
12. Focusing on the Current State First
13. "We're Done" – EA is never done, setting up a continuously evolving process serving the business needs

Kyte discussed several best practices in application architecture in the context of EA, and started by remarking that many enterprise architects are former application architects and they tend to focus on the technical software solution. He recommends that one should take a step back and have a broader view of the solution’s entire ecosystem, evaluating how the solution is going to perform over time in a continuously changing business landscape:

We need to be thinking about the lifecycle, we need to be thinking about the blend of services, the operational services, the maintenance and support services, the enhancement and extension services, the business intelligence services, the whole blend of services that will be needed throughout the life of the application ecosystem. Then we can say … what are the characteristics that we want to built into the artifacts to ensure that we get there….

How this will deliver us the characteristics that we want in terms of agility, responsiveness, and reliability? How do we ensure that those characteristics are maintained throughout the life of the ecosystem?

Kyte suggested judging a project’s success not by measuring how well it runs when it is launched, but by how well the “system meets all of the requirements of all of the stakeholders over the life of the system.”

Kyte also discussed the role of the application architect in achieving software quality. He started from ISO 25010 which defines software quality in terms of 6 elements: Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability. He drew attention to the fact that some architects focus too much on functionality aspects of the software, noticing that these requirements are changing due to regulatory, competitiveness, and business requirements: “We might have been right when the ink was wet, but the time the ink is dry they are already out of date.” Since change is constant in the life of a system, architects should consider all the other attributes of software quality mentioned, especially Maintainability, which helps dealing with change if it is properly done.

Kyte mentioned several sub-domains of Maintainability: Analyzability, Changeability, Stability, and Testability. Analyzability represents how easy is to analyze and understand what the system does. If the answer is “Read the 860,000 lines of Java and you’ll understand what the system does, I think it is not very high on the analyzability criteria.” Kyte believes that one needs to consider consider documenting the code and the process workflow, increasing the analyzability of the system.

As a conclusion, to achieve success an architect should consider and evaluate the outcome of his application in terms of Annual Costs, Lifespan, Functionality, Agility, Portability, Usability, Reliability, and Cost to Create.

As good practices, Kyte recommended paying attention to details, being involved into all the phases of application development, including sourcing arrangements, and being involved in the governance process.

Resource: Slides (PDF).