When it is (not) amicable …

No one tells you about the excruciating details of separation. Nor the emotional or mental strain that you have to deal with.

Sure, people talk about anger, angst and sadness. Far too often it is wrapped in the package of an acrimonious split – an event or action that like a grenade in a lake creates a massive splash and then ripples out to each bank.

No one talks about a split that is made when it’s obvious that the relationship is no longer working.

Continue reading “When it is (not) amicable …”

Silver is not the colour of the lining (of my fuck-tonne of baggage)


Ain’t nobody got time for that

You should probably do something better with your time.

NB; This is part of my CB therapy. It’s one sided, it’s biased, it’s self pitying, it’s my mind and nothing else. If you happen to know me and happen to know anyone I allude to, then take it with a horse bag of salt. There’s so much left unsaid and so much probably overstated. That’s the nature of externalisation based writing therapy.

Continue reading “Silver is not the colour of the lining (of my fuck-tonne of baggage)”

embrace the complexity

We live in times awash in simplicity and simple-minded thinking.

But life is not simple. Nor are the challenges and issues facing us all, yet our culture seems to thirst for the false dichotomy of simple answers to complex problems.

We seek the simple. We want simplicity.

Thus, I feel that everyone misses the point.

Simplicity isn’t and nor should it be the goal.

Complexity, whether we like it or not, is the point.

Continue reading “embrace the complexity”

Which Enterprise Architect did you mean?

The IT industry has a magnificent history of appropriating titles and then through the process of demand outstripping supply, diluting the skills and requirements for those roles to a new lowest common denominator based average.

Continue reading “Which Enterprise Architect did you mean?”

The Fool, the JourneyMan, and the Expert

Whether I talk about my earliest stints as a masseuse, my forays into agriculture, professional photography, or the mainstay of my employment, the Business Information Systems and Technology fields — for much of my working life, I have been teetering on the see-saw of comparative knowledge.

Continue reading “The Fool, the JourneyMan, and the Expert”

Is EA broken? Does EA have value?

These are the questions de jour on many forums, in recent trade articles and across the LinkedIn environment. It would be easy to simply respond with “no” and move on, but nobody has time for such a short response, so this longer response is required.

I have always been a huge fan of utilising analogies to explain concepts, so I shall not deviate from my previously successful actions and do the same here by exploring EA via the analogy of a Marketing Plan.

I doubt anyone would disagree these days that any corporation should operate without a Marketing Plan and that as such, any efforts expanded by a corporation would otherwise, at best, be considered ad-hoc and, at worst, wasteful and disorganised.

A Plan is, according to many dictionaries, defined as “a scheme, program, or method worked out beforehand for the accomplishment of an objective”.

A marketing plan is not a spreadsheet of activities. It’s not an editorial calendar. It’s not a list of surveys, research assignments and campaigns. It’s not a budget or set of goals. It isn’t a set of articles or models from McKinsey. It isn’t something you think you have in your head.
It is a strategy.
It helps focus resources.
It is a plan for activities that stimulate objectives – like sales and growth.

The planning process helps you to understand the different factors that may affect your success. The process of creating a strategy plan involves three steps:

  1. An analysis of the firm’s internal and external environments;
  2. A decision on the what to emphasise and project; and
  3. The selection of action plans to guide the enterprise.

The very first, and arguably most important step, is to perform research and analysis of your business and the market it serves. Once you are confident that you know your business, your market and what you have to offer – then define your goals. With your goals in sight, you will then need to determine the guidance and tactics you will undertake in order to achieve them. Ideally, by mapping them into your landscape via some situational awareness.

Now, instead of worrying about the future, you actually have a sense of control over your direction, because your decisions, and any unexpected issues, are guided by an overall map and strategy governance.

This is as true for Marketing plans as it is Enterprise Strategies.

Throughout the processes of creating, implementing and evaluating your plan, it is important to realise just how valuable mapping and planning is for your company.

The secondary question of frameworks, methods or schools of thought are, to my mind, of little consequence in the overall argument. No amount of textbook correct implementation of FEAF, Zachman or <insert sparkly-new-fandangled framework here> is of any use if it does not produce – and communicate – a plan.

An Enterprise Architecture, just like a Marketing Plan, is a strategy that functions as a blueprint for everyone within the organisation to not simply see, but also to be guided by and follow. The company as a whole will know in what direction it is going – thus causing energy and efforts to be amalgamated and focused.

If you are not doing this as an EA, then yes, I may be inclined to agree that you are the problem and, by extension, your company is likely to believe that EA holds no value.

Whilst I may disagree with a few of the definitions spouted by many respondents and claimants of expertise across the many forums and articles I have read, my initial yardstick of measure will be the success the communication of “the plan” has had on the non-IT departments of the corporation – namely the support they offer and the amalgamated effort that is spent by those departments in aiming to achieve its success.

More rambling thoughts on Solution/Enterprise Architecture

What is EA?

This question, frankly, is the largest issue across the industry and thus the reason my initial response is such a mish-mash of definitions. Essentially, it comes down to a difference of opinion within the base premise of Enterprise Architecture:

  1. EA is an IT discipline
  2. EA is a BUSINESS discipline

What (mostly?) everyone does seem to agree on, however, is that it is based on providing a business outcome through governance and strategy.

I will tell you up-front, my personal bias is towards the second perception – ie. a business discipline. To my current state of mind, this creates two definitions of EA being:

Enterprise Architecture: Noun: “Enterprise Architecture is organising logic for key business processes and capabilities reflecting the integration and standardization requirements for the firm’s strategic objectives and operating model.”

Enterprise Architecture: Verb: Enterprise Architecture is the process utilised in the aim of making better enterprises.

The Building Industry Analogy

I have a penchant to return to the building industry analogy to describe the structural breakdown of an Architect from Enterprise back to Solutions, Domain, Technical and Engineer levels.

The Enterprise Architect is the City Planner. They’re looking to solve larger issues that will affect the total landscape. They consider the interactions of the entertainment zone, development, farming, residential and industrial zones. This will require a number of considerations – infrastructure, telecommunications, waste management, traffic management – and the broad range of areas requires that they cannot get stuck on the miniscule details. Thus, they need to consider minimum guidelines that will become the planning regulations (governance) for the city (corporation) to be followed by those that begin the implementation work. The EA has a BROAD knowledge base across multiple domains.

Solution Architects are Town Planners. Like the Enterprise Architect, they are focussed on managing the governance and strategy for a range of domains, however, they are focussed on a smaller level whether or not it is part of a larger Enterprise (City). Like the EA, the SA also has a BROAD knowledge base across multiple domains, though may still have some strong depth in key arenas as they often “graduate” from Domain Architects.

Domain Architects: These are cross-specialty multi-domain experts. Unlike the Solution Architect, they are often focussed on a range of complementary domains in which they have some DEEP knowledge accentuated by a BROAD base. In the building industry, these may be Architects who focus on Industrial Estates, Shopping Centres or on estate-wide water and utilities planning. In the world of Business and IT, we can consider these to be Industry or Portfolio Architects, Consulting Architects or simply Information System Architects.

Technical Architects: The draughtsmen of the industry. These are the people with the deep skills in a certain domain. They pull together the governance, strategy and requirements and develop an implementation design that meets the unified scope. A Data, Applications or Infrastructure Architect all meet this definition.

Engineer: Like in the building industry, we often make use of specialists to determine the finalk design meets the specifications for a particular domain or speciality. These are the people who do the detailed work on the plans. This can include DataBase Architects, Firewall Architects, Design Engineer or Engineering Architect.

see a model I tried to represent a while back

Why do I blather thus? Because, in my world view, an EA should be able to take up the reigns within any industry and utilise their skills, knowledge and abilities to make use of any of the skillsets of the “architects” for that industry.

Technology is not simply IT.

On EA vs SA and the debates over Frameworks

If an EA team is concerned with the enterprise-wide optimisation of business systems, then some form of understanding is required – a framework assists in the processing of that understanding. A framework, after all, is “a basic structure underlying a system, concept, or text.” Essentially, it matters not if you utilise Zachman, PEAF or some strange mystic runic system as long as it is consistent, communicable and functional.

If it assists in improving business systems whilst ensuring management and stakeholders understand the impact so as to commonly work towards minimised risks and maximised opportunities – then does it matter? In the end, the goal is to improve the enterprise and the measure of that should be in the reduction of complexity and increase in agility?

TOGAF may not be a “an all-out, wholehearted, EA method” – however – it does lead the primary audience of the (related) craft towards it through the influenced accumulation and iterations of TOGAF from IT Architecture (back) towards Enterprise Architecture. In fact, I would not be surprised to see the future iterations begin to incorporate elements from other frameworks to bolster it towards TOGEAF.

To iterate, if the process you are undertaking, regardless of framework utilised, is tactical, then it is a SOLUTION Architecture. If the process you are undertaking is far more abstract, defining strategies, policies and standards for cross-organisational and enterprise wide strategic value, then it is an ENTERPRISE Architecture.

The knowledge path for EA

So what is the path for an EA? I’m still nutting that one out and has been part of the overall discussions and debates that surround the process of the restructuring a curriculum in the corporate university for the training and guidance in the graduate programme.

My  personal view encompasses that TOGAF should be part of that learning path for all aspirational EAs and should perhaps even be incorporated into the MBA. I have often used my analogies and “alternative technology examples” in discussing and teaching the ADM – it offers a better grasp of the framework for thinking beyond one’s own responsibilities and in considering the larger enterprise and stakeholder landscape.

However, as stated above, TOGAF is still very much a tactical, change implementation focussed Architecture Framework as essentially, you can break up the ADM into 4 core groupings – Getting the vision right & the organisation committed (Prelim & Phase A) – Aligning the Architecture (B / C / D) – Managing the Implementation/Transformation (E / F / G) – Manage & Maintain the Operations (H / Req Mgt). It is thus thoroughly necessary to ensure a range of aspects – including unified taxonomy and standardised processes.

Does an EA need to follow a layered approach? Should they be exposed to the Delivery or domain architectures? What should they look like if that is the case? Would people agree with this as a basic map and overlay view?

Is this the Architecture layer map?
Is this the Architecture layer map?
Layered Skillsets and capabilities?
Layered Skillsets and capabilities?

Most of the areas of additional learning arenas that come into play towards discussing the EA training path – such as skilling up with the BABOK or PMI – really are just boosting or rounding out the skills within the ADM, they aren’t really furthering the skills and mindsets towards the enterprise wide strategic value element of EA thinking.

So what assists with that element of thinking and skilling up? What should be part of the toolkit for the aspiring Enterprise Architect?