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.

Develop (and Execute) a Communications Plan – communicating back to the business, outlining the value of current EA developments.

Be Pragmatic (scope and iterate your efforts)

Treat Each Iteration Like a Project – EA is not a project, but each iteration can be treated as a project

Start With the Business Strategy and Obtain Business Sponsorship

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.

Don't Forget Governance – the enterprise architect is “facilitating, guiding, collaborating, and helping people work across the organization”

Set Up a Measurement Program (link to overall performance management) – measure the effectiveness of the EA program

Track EA Program Maturity and perceptions – people usually have different perceptions on their organization’s EA maturity, sometimes very different

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:

No Link to Business Strategic Planning and Budget Process

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.

Lack of Governance

Over-standardization

Focusing on the Art or Language of EA Rather Than Outcomes – the business outcomes should drive the entire EA efforts

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

"Ivory Tower" Approach

Lack of Communication and Feedback

Limiting the EA Team to IT Resources – it is recommended to have business people on the team

Lack of Performance Measures

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

Focusing on the Current State First

"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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.