For Enterprise Architecture training see https://trainingbrite.co.uk/
-
Recent Posts
Archives
Categories
Meta
what is architectural thinking
Normal thinking becomes architectural thinking when two criteria are met:
- Architectural thinking is thinking with a purpose. Thinking how to best articulate a complex issue, solve a problem, make a difficult decision, tell an intricate story; these are all examples of thinking with a purpose
- Architectural thinking occurs at least across 3 different dimensions. For example thinking architecturally about a new building should probably consider at least the dimensions of space, time and people (the architect that doesn’t think about the people using the building is unlikely to succeed).
Business needs, cost, technology and users are some important dimensions (there are also others) for developing IT systems. What-Why-Who-When, Current-Target-Gap are other useful generic dimension. If you can’t find a third relevant dimension (e.g. you should only worry about cost and comfort when you buy a pair of shoes!), there is no need for architectural thinking.
Minimum Enterprise Requirements
Believe it or not, many people in IT and business are still struggling with the concept of Enterprise Architecture, and the actual value it provides to the organisation. The theory is clear, less so how it translates into real value in practice.
The need for well articulated and clear Requirements, however, is well understood. And people generally understand that designing and implementing IT Systems to satisfy requirements generates value to the firm.
Rather than EA and Architecture Standards, I prefer to talk about Minimum Enterprise Requirements (MERs).
Enterprise Requirements are requirements that exist beyond the boundary of a project or program. They are Minimum when satisfying them is not discretionary. Typically, requirements deriving from a security policy, regulatory demands or strict business constraints are good candidates for MERs.
A MER is a requirement coupled with a clear applicability trigger criteria. This is important, because designing and implementing MERs can (and normally is) expensive. Whether a MER applies to a specific IT System needs to make business sense. Implementing Security MERs to provide a very high level of assurance, for example, makes only sense if the IT System stores/processes/displays data that is classified as strictly confidential.
I often use the example of Building Regulations to explain MERs and triggers. 
Building regulations contain the rules for building work in new and altered buildings to make them safe and accessible and limit waste and environmental damage. People carrying out building work must usually arrange for their work to be checked by an independent third party to make sure that their work meets the required standards. In some cases the installer can certify themselves that their work complies (https://www.gov.uk/government/policies/providing-effective-building-regulations-so-that-new-and-altered-buildings-are-safe-accessible-and-efficient). In other words, if you’re building a hospital, there is a MER for disabled access. It’s applicable to all hospitals, and is not discretionary!
To evaluate whether a MER is a good MER I have devised a TUSIV test. As such, MERs must be:
- Traceable (to a business approved firm policy, standard or directive)
- Unambiguous
- Singular
- Implementable
- Verifiable
Architecting Capability and Architectural Significance
Building and maintaining a mature architecting capability is not cheap, especially in large global organisations. Typically, with a program/project portfolio in the hundreds, it is impossible to assign good architects to cover the entire portfolio.
Even merely trying to achieve an effective
architecture governance, well integrated with the broader IT governance processes, is in itself challenging and often impossible for a portfolio of that size!
Relatively to many other IT areas, architecting is an expensive activity, and investing in it must make business sense. Just like architecting in the construction’s industry, you wouldn’t hire a top architecture firm to extend your kitchen or build a standard block of flats; not only you would struggle to hire and retain a top architect and make the most of her expertise, but also the cost of a top firm would not be justifiable for such projects.
Allocating the best architects where it is most needed happens ad-hoc in small IT shops, but with portfolios in the region of several hundreds IT programs, and a typically resource-constrained architecting practice, in large organisations the work of highly skilled architects must be prioritised systematically.
This can be achieved by introducing the concept of “architectural significance”, and classifying the entire portfolio accordingly. Typical values of architectural significance are High, Medium, Low and Unknown. As a rule of thumb, less than 5% of your portfolio should be of Unknown Architectural Significance (UAS) at any time, and publishing monthly metrics on the architectural significance of your portfolio is a good incentive to minimise the “unknown” and build a good understanding on the architectural relevance of the program portfolio.
Once you understand where the architectural need is greatest, a more optimal resource allocation is possible. For programs of High Architectural Significance (HAS) it makes sense to assign good architects from early on to collaborate with the program on a continuous basis, often with the responsibility of leading the architecture and design work. For programs of Medium Architectural Significance (MAS), a one-off architecture review is normally sufficient, whilst no architecture engagement is typically required for programs of Low Architectural Significance (LAS).
To make this work, an effective collaboration with portfolio/program/project managers is required, and these are some good practices to encourage that:
- don’t capture architecture significance on an isolated spreadsheet; much better to extend the data model of the portfolio management system to capture architectural significance and other architecture engagement attributes (Lead Architect, Lead Reviewer, architecture milestones, etc.)
- involve the portfolio and the program manager when deciding whether a certain program is of high architectural significance
- publish criteria to help decide the degree of architectural significance; budgeted expenditure is one of many criteria, others should be alignment with target architecture, impact on strategic systems, etc.
- produce a short e-learning module and other artefacts (architecture engagement in 1-page) targeted for that specific audience
I have introduced architectural significance as a way to modulate architecture engagement twice now, and I know it works.
Posted in architecture capability, Process, Uncategorized
Tagged architectural significance
Leave a comment
Fit for Purpose Architecture
I struggled to find a satisfactory definition of fit for purpose architecture.
Here is the best I could come up with. Please suggest any improvement you can offer, and add links to other definitions that you found helpful.
A solution/application/system/service architecture is fit for purpose when it is acceptably and reasonably:
– fit for its intended purpose: does what it’s supposed to do (meets the requirements of its users and sponsor)
– appropriate: is aligned to the existing strategy and as congruent as possible with the target architectures and roadmaps
– of a necessary standard: adequately addresses the concerns of those stakeholders with enterprise requirements
– economically viable: implementable within a reasonable time and at a reasonable cost
Enterprise Requirement is a requirement that exists beyond the boundaries of the program. These are sometimes referred to as standards, policies or constraints. Regulatory, Security, Strategic alignment, Business Continuity, Operability, Outsourcing, Policies, etc. are examples of enterprise requirements.
Not deliverables, but architecture consumables
waste please (Photo credit: blakley)
Let’s face it: IT architects produce a lot of what I would call “architectural waste”. Too often, the focus is on architecture deliverables. We deliver them, and then we start working on the next deliverable.
Unfortunately, architecture deliverables that remain “unconsumed” are not generating value: yes, it’s architectural waste! Think of the IT Value chain: what we produce should be consumed by the next step in the value chain to ultimately generate value to the firm. Another useful metaphor is that of intangible assets in a balance sheet: an architectural asset is such only if has a value and can be turned into cash! If the cost of acquiring the asset is greater than the actual value, you will need to write off at some point in the future.
A roadmap that remains on a powerpoint slide, a solution architecture ignored by the project delivery team, a too abstract corporate data model, an unrealistic target application architecture, a forgotten architecture vision: these are all examples of architectural waste. To avoid this, we need to make sure that they are considered as assets and therefore consumed by the next step in the value chains, and eventually become value delivered to the firm.
We should stop thinking in terms of architecture deliverables, and start thinking in terms of architecture consumables. Here are a few tips on how to do that:
- Make it clear what type of work products you are planning to produce; there is only a few possible of types: 1) a strategy or position paper; 2) a plan or roadmap; 3) a (current or target) model; 4) a gap analysis; 5) a technology evaluation paper; 6) a policy or standard; 7) a service definition; 8) a service or application. Granted: this is not a complete list, but you get the idea…. A good architecture practice will produce a healthy mix of those consumables.
- Make it clear how your consumable fits in the overall IT value chain. In other words, be explicit on who your consumer/customer is (within IT or business). Simple rule: no customer, no value!
- Think and communicate what the purpose of the work product is; why will be be useful to those consuming it, in other words, what’s the value proposition.
- Be explicit on the planned completion date. Be realistic and explicit (too many architectural efforts go on, and on, and on…)
- Communicate the dependencies (in other words describe what’s the previous step in the value chain), but expect to be challenged. There will always be dependencies, but you have to make a call on whether you enough data to proceed with your work or not.
- Define the success measures. A very important measure is probably your consumers/stakeholders’ satisfaction, but you should be able to have other measures too. For example, for a plan or roadmap securing the funds for its execution is a good success criteria. For a standard, its degree of adoption (anyone can define a standard that nobody follows…).
No more deliverables, but architecture consumables….
Posted in architecture capability, Process
Tagged "architecture capability", architectural_waste, architecture, architecture consumables, architecture deliverables, architecture value, architecture_asset, architetcure value, asset, Consumables, Deliverable, value, Value chain, value of architecture, Value proposition
1 Comment
English: Capability management (Photo credit: Wikipedia)
I think of IT Architecture Capability as the combination of people (their competencies and skills, regardless of their team names or job titles), methods, information and supporting tools that allows an organization to consistently produce IT products with a fit-for-purpose architecture, cost effectively.
I believe that Architecting IT solutions that are fit for purpose is an important business capability in many enterprises. Not strategic, in most cases, but definitively important. It needs to be done well, and it needs to be done cost effectively.
Being a business capability, I would argue that the architecture practice of an IT organisation should be run like a business, competing with other business capabilities (marketing, operations, sales, etc) for organisational resources to generate value that exceeds the cost of capital. As such, traditional technical competencies are necessary but insufficient to be successful. An organisation designing the best cars in the works, will fail without supporting competencies in marketing, production, performance measurement, supplier management, quality, and many other disciplines.
Ultimately, to be successful, an architecture practice needs to provide to its stakeholders (within and outside IT) what they need, cost effectively. Worth repeating: to be successful, your architecture practice needs to provide to your stakeholders what they need at a reasonable cost.
Architectural Thinking - Applied Architecture for Solutions and Enterprises 