7 habits for developing a Technical Architect Mindset

  1. Decisions are not dichotomies of either/or.
    It’s not clicks or code, its clicks and code, or clicks at first, and then replacement with code. Or too much code, for the wrong reason, or too many clicks, for the right non-functional performance requirements. Some questions aren’t ‘Should I do this in clicks or code’ its ‘Should we do this at all’ or ‘What happens if I do it this way?’
  2. Becoming an Architect isn’t a destination.
    It’s a progressive journey that does not end. It may reach an inflection point (with a job title), but it’s not a mountain you climb where you reach the top and gaze down on the world below.
  3. You can’t study all the answers, but you can seek the experience.
    There is no book of ready-made answers to every situation. There are only things you see and hear and read. Ideas picked up from colleagues, war stories told by clients or friends, that project that failed, that idea that didn’t work out, that thing that succeeded. You do it over and over and over. The study gives you ingredients but cooking the meal, that comes from experience.
  4. There are no right answers. There are principles to learn and apply.
    There are better or worse answers, depending on the circumstances. Do you know all the circumstances? Have you considered the options for the answers? Do you know the questions to ask?
  5. It’s not about being ‘right’
    Indeed, you might not know if the design has succeeded or failed until years later. What was a success could be declared a failure with changing business conditions, changing assumptions, changing politics, changing technology. Often the right answer isn’t easily seen, it is simply your answer, supported by the reasons you can articulate and accepting the trade-offs you know come with it. If you think you are the smartest person in the room… then you are on your way to failure. Staggering insecurity is a feature, not a bug.
  6. The idea is the easy part, the persuasion is where all the work is.
    Can you convince a room full of people they are looking at the problem the wrong way? Can you justify your choices with the right props? Can you use diagrams, analogies, examples, stories, a raised voice or a timely question to win over a group of people?
  7. More here: https://www.youtube.com/watch?v=ND-dX-__I1Y&t=528s

From https://limitexception.com/another-7-habits-for-developing-a-technical-architect-mindset-448c9f3fec13

Learn to spot Unicorns

Horns, horses and wings exist.

Unicorns do not.

Just because you can talk about “proactive infrastructure”, a “dynamically configurable platform”, or “contextually aware flow routing”, doesn’t mean they exist.

There are a lot of folk out there selling Unicorn architectures.

Learn to subject proposed architectures to common-sense, plain-English reality checks.

7 Key Enterprise Architecture Metrics

Enterprise Architecture is still an emerging field. There are not many organizations today that are effectively measuring their EA program with metrics. Here are a few metrics that might work:

IT Total Cost of Ownership (TCO) as a Percentage of Revenue
One of EA’s value propositions is reducing costs by leveraging common solutions and rationalizing processes, technology and data.
This metric is key to the business value achieved by the IT stack. It has appeal to business stakeholders and allows IT costs to be compared with industry or regional averages.
Example: The total cost of ownership of IT is 4.8% of revenue.

Total Cost Savings (TCS)
Often EA is able to achieve cost savings by:

  • retiring a legacy system 

  • consolidating licensing 

  • introducing common shared services 

  • rationalizing infrastructure investment 
    If the EA team can deliver cost savings on a regular basis — Total Cost Savings is a meaningful metric for EA.
    Example: EA initiatives saved the organization 5.2 million dollars this quarter.

Percentage Of Spend That’s Strategic (PSTS)
The EA team assesses all projects and designates them as tactical or strategic. The percentage of the total IT spend that was considered strategic can then be calculated using project budget information.
PSTS is a good predictor of the long term heath and efficiency of IT. However, it may be of little interest to the business.
Example: 47% of project spending went to strategic projects this quarter.

Common Services Compliance Rate (CSCR)
Enterprise Architecture often defines common services such as ESB, BPM, Infrastructure platforms etc… The CSCR measures the percentage of new projects that are fully compliant with the common service roadmap.
Example: 67% of projects complied with EA’s common service strategy this year.

Architectural Due Diligence Rate (ADDR)
The percentage of projects that are fully compliant with the EA governance 2 process. A EA governance process involves steps such as updating EA blueprints, architectural reviews and macro design.
ADDR is a good metric for reporting violations of the EA process. It is often helpful to report ADDR by business unit, technology silo or project manager — to highlight problem areas.
Example: 78% of operations department projects complied with EA governance but only 12% of sales department projects were in compliance.

Sunset Technology (ST)
Percentage of the technology stack that is considered sunset by EA. Measures IT’s ability to introduce strategic technology and retire legacy systems.
Example: At the end of the year 54% of production systems were deemed sunset technologies. This compares with 62% last year.

Business Specific
Manage EA with specific metrics aligned with your business strategy and goals. Examples include:

  • reducing time to market for launching new products 

  • reducing human error rates 

  • speeding up order delivery 

  • reducing IT costs 

  • reducing severity and frequency of security incidents
    Example: average time to market for introducing a new product decreased from 5.8 months last year to 4.9 months this year.
    Significant and measurable business goals that require EA support make good EA metrics.

The 3 Types of EA Metrics

There are 3 fundamental ways to measure the performance of your EA team:

1. Measure IT
IT metrics are well established — ROI, Total Cost of Ownership, Mean Time to Repair (MTTR) etc..

Such IT metrics are SMART and appeal to the business. They are good measures for IT — but do they translate to EA?

In theory the EA team should be able to increase ROI for IT, reduce Total Cost of Ownership etc… However, there are many factors affecting these measures. The correlation between EA performance and IT metrics may be low.

2. Measure EA Governance
It is relatively easy to measure the success of IT governance. What percentage of projects complied with governance? What percentage of projects were rejected? The problem with these metrics is that they lack appeal for the business.

It is not obvious how governance metrics translate into competitive advantage, customer experience or cost savings.

3. Measure EA Itself
Measuring EA directly is the ideal way to score the EA team. The problem is it is tricky to develop such metrics. The EA team collaborates with business, solution and governance teams.

The fact is that it is difficult to assign a number to collaborative long term planning activities such as EA.

EA is Strategic Planning

Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed.

How does an enterprise react to events that do and will potentially occur and arrive at the strategies needed to remain robust, efficient and viable, to continue to deliver value and make profits for themselves?

Enterprise Architecture is the corporate discipline that helps us to understand the questions that need to be asked and get better at strategic thinking. The approach is based on asking the usual Why, What, How, When, Who and Where questions:

  • Why does the enterprise need to change?
  • What are the drivers for change?
  • Are the drivers fully understood?
  • What is the mission and purpose of the enterprise?
  • What do enterprises need to do and need to understand? What do their customers and stakeholders want?
  • What is possible to do?
  • What are the strategies, goals and objectives?
  • How will these be achieved?
  • What business capabilities are needed?
  • When should the enterprise react to new opportunities? What are the potential business scenarios that might occur? How will the enterprise react when they do occur? And how should it react?
  • Who should be involved?
  • Where is the enterprise?
  • What environment or markets is it located in?
  • How many different environments are there?
  • What would success look like for strategic planning?

These should all be open questions. You should take care that the questions don’t upset those executives that are responsible for the current answers and are asked in an ego-less fashion.

All of these answers can be modelled and analysed with your favourite enterprise architecture tool.  I like to add a Strategy domain to the usual Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture domains.

Enterprise Architects should start to think like a strategist instead of just like a technologist.

From https://ingenia.wordpress.com/2013/01/20/ea-is-strategic-planning/

Ten Ways to Kill An Enterprise Architecture Practice

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

From http://blogs.msdn.com/b/nickmalik/archive/2013/09/05/ten-ways-to-kill-an-enterprise-architecture-practice.aspx

EA Generalist

A generalist knows a little about a lot of things, and, crucially, how to connect them together. Good generalists are well aware that they are actually quite small fish in what is often a very big pond.

A specialist knows a lot about a single often very-little thing. Good specialists can be quite big fish, though only in a relative sense within their own often quite small pond.