I heard this quote the other day, but I didn’t catch who originally said it.
Art requires rigour, science requires creativity
The first point is that it’s contrary to the standard view. The second point is that both perspectives are valid and that there shouldn’t be that much of a difference.
It then made me think of typical transformation programme roles and the relation between creativity and rigour. Most roles have a balance between the two, with that balance changing according to the standard role and, at times, according to the demands on that role.
For instance, process analysts should generally follow a set of standards. Business Analysts have to be more creative, but still have methodologies to follow. Service Designers have less rigour methods, usually a composition of tools and techniques rather than the standardised methodologies of previous decades. At the more rigorous side, project managers have their methodologies and frameworks to follow. Programme managers see a wider scope and have more creativity in organising the interdependencies. Which then fits nicely with my normal comment that a Business Architect has more in common with a Programme Manager than a Project Manager; there are more skills in common, even though the professional methods involved are different. Which leads me to the Business Architect who has to know when to be standardised and when to be creative. There has to be the flexibility to modify the approach to suit the needs of the client, depending on the stage of transformation.
I’m going to use GDPR as an example of how prioritised goals can make a big difference in how an organisation responds to change. I’ve no wish to jump on the consultancy bandwagon that is GDPR; I’m definitely no expert on the subject. However, GDPR will serve as a good example in this content as it’s a topical subject that many organisations are addressing and so should be at the forefront of many strategic and tactical discussions.
A brief perspective on GDPR
I have a simple view of GDPR in that it’s requiring organisations to be better citizens, i.e. to behave better with the data that they obtain and manage. While there are a those complaining about the effects of GDPR, I would first want to question the motives of the companies they work for. I would be looking to see whether the motives are customer-centric or profit-centric. For most customer-centric organisations, most of GDPR is doing what they do already, but with some more rigour to their processes. Unfortunately GDPR is a bit of sledgehammer and a few other nuts will get cracked.
GDPR has stronger implications for what can be done with customer data, potentially rendering data useless collected in such a way. Actually, it goes further in terms of legality of handling and processing data, but we’ll stick to usefulness to the company for now. The important point is that for many companies, there will have to be some changes to how they collect data in that manner and potentially if they continue to collect it at all.
Business Motivation Model
So let’s apply business motivation model and see what GDPR looks like in this case.
The above diagram depicts two companies. One on the left and one of the right; there’s a gap between the top. It is a simplified business motivation model showing the difference between the two organisations, based on one single goal at the top.
For the left-hand company, the main goal is to Provide the best customer service possible. They are achieving this through a sub-goal (maybe a mission in many organisations) of Build relationships with customers. This goal is achieved by the outcome of Capture Customer Contact Details. I’m simplifying to allow outcomes as measurable effects that will happen.
The outcome is realised by a process group of Ask for details of customer which is part of the Pre-GDPR state or plateau. That process group fulfils the outcome for the situation before GDPR. We’re interested in what happens in reaction to GDPR.
In the same company, we can see GDPR as a external driver. The company conducts an assessment and we have a goal of Be GDPR compliant.
That goal influences Capture Customer Contact Details.
We have a work package designed to achieve that goal of Become GDPR Compliant.
For the Post-GDPR state, notice that there is a revised process group of Revised Customer Engagement. This process group focusses on building the relationship. It’s implemented by the Become GDPR Compliant work package. You can trace the line up to the goal of Provide the best customer service possible and the driver of GDPR
Meanwhile, on the right-hand side, we see a similar motivation model, but with some differences. The GDPR elements remain the same. What has changed is the overall goal of Increase Revenue which includes the sub-goal of Increase Revenue from Individual Customers. To achieve those two goals, we end up with a different process group for the post-GDPR state. The result is the same as the original process, but prefaced with an explanation of what we’ll use the data for, etc.
The Business Motivation Model was simplified in this case. I’d expect to see design principles/constraints, more detailed goals and objectives on the company-side and more detailed goals and objectives on the GDPR assessment side. All of those would constrain the future design.
For instance, the revised process groups I’ve displayed are not the only options that meet the listed goals. However with more goals and outcomes included, I’d expect there to be fewer options to choose between.
The examination of the GDPR scenario through a Business Motivation Model indicates at least two responses to a common data collection issue.
The end result is that it:
may speed up queues since companies realise they can’t just ask for contact data and they decide to not ask,
may speed up queues since companies realise that the interaction doesn’t allow for valuable data to be collected since they won’t have an agreement to use it and, again they decide not to ask, or
may elongate queues so that the companies can ask for permission
Back to the title, I see options (1) and (2) being the white knights for the customers of many companies. We’re hoping that companies follow common sense and implement changes that both respect the customer experience and adhere to GDPR. However in addressing the elephant in the room of how processes can be changed to suit GDPR (rather than improved for the customer), we may end up with (3) and a worse customer experience.
In Black Sheep or Shepherd, I introduced the idea that Business Architecture isn’t aligned with Enterprise Architecture as well as we may expect from looking at traditional structures for Enterprise Architecture.
I’ve had several conversations about that topic since, all raised by the person I was talking with, rather than me asking them. And we’re all coming to similar set of conclusions:
Business Architecture doesn’t fit well within Enterprise Architecture (more on this below)
Business Architecture as a profession is maturing
Organisations who are using Business Architects are using them differently
Business Architecture may be better defined as a peer capability to Enterprise Architecture, rather than within EA.
Let’s take each in turn.
1. Business Architecture doesn’t fit well within Enterprise Architecture
I covered a lot of this in Black Sheep or Shepherd. The traditional implementation of EA originates from an IT perspective. Enterprise Architecture is typically initiated from with the IT function. While EA is meant to include Business Architecture in parallel to Technical Architecture, etc, Business Architecture is typically the last to be included and takes a position following Technical Architecture.
A typical Enterprise Architecture structure would include Application Architecture, Infrastructure Architecture, Data/Information Architecture and Business Architecture. Usually implemented in that order when originating from an IT perspective. In fact, I’ve often seen the sub-architecture of Process Architecture being implemented before Business Architecture.
This is opposite to what we would expect if we were able to plan it logically. In that case, we’d apply Business Architecture first in order to understand the aims and vision of the organisation, then organise everything around that vision. That’s where the other architecture domains come in. That’s the method as described (but often not followed) within TOGAF ADM. Start with the agreements, architectural principles, then business architecture to define the requirements for the other architecture domains.
2. Business Architecture as a profession is maturing
While we could say this of almost any profession, the rate of progress and thought-leadership in Business Architecture has progressed noticeably over the last few years. Prospects and clients are more aware of what it can do for them, internally within organisations there are more allies for the need for Business Architecture. It’s not all rosy, but it is improving.
Not only are the consultancies improving in their offer and the clients are improving in their knowledge and their requests, but short-term resource agencies are also improving in their placement of business architecture. More people involved in the wider enterprise are now talking about the value of business architecture. It’s still not prevalent and there’s often sales activity involved in influencing clients and prospects in the value, but it is increasing.
3. Organisations who are using Business Architects are using them differently.
Many of my requests for work come from portfolios or programmes rather than central, corporate enterprise functions. It is the change function of the business that is seeing a need to create order within the organisation and hence wanting the services of a Business Architect to assist with that. Typically, these assignments also stretch into guidance on business analysis although that can be considered separate. The indication though is that’s how the clients are seeing the tasks at hand. They see that the technology is taken care of through technical design authorities, etc and want a similar structure for business decisions.
This can be extended to a point where a change programme uses business architecture which then informs a corporate function. That corporate function realises the value and initiates their own business architecture initiative. When done well, these two different business architecture functions concentrate on their own objectives while ensuring alignment between corporate and change function. When done badly, they compete.
4. Business Architecture may be a peer capability to Enterprise Architecture
I find myself discussing future designs with Enterprise Architects, not because the designs have to go through them in terms of governance, but as a peer review. It does raise the question of whether they’re should be a consolidated governance route and review boards, not just technical design authorities. I have created design authorities that focus on business design (including the use of technology) rather than the technology solutions as would often appear before a technical design authority.
In addition, if we take the EA implementation diagram mentioned earlier, we can see that there are several transition states; one after each phase where only a subset of the Enterprise Architecture has been implemented. The typical transition state follows phase 2, where we see EA comprising Infrastructure and Application Architectures, all governed through an EA route. But with Business Architecture and Data/Information Architecture governed through other routes.
That combined, with the multiple design authorities, is indicative of an immature EA function, leaving us with two choices:
Improve the maturity of the EA function and the role of Business Architecture within it.
Engage Business Architects as peers to Enterprise Architecture
(1) only works if the initiatives are not IT focussed and that there’s more well-rounded support and engagement for that function.
(2) is what many clients are doing. They’re seeing EA as not performing what they require of the function, so they engage a Business Architect to provide and cover that gap.
Where to go from here?
That leads me to my premise. Even though EA is mature as a concept, it’s implementation is poor in a number of organisations, especially those that treat EA as a subset of IT.
Wherever EA is a subset of IT, then Business Architecture should short-term be driven by change portfolios. In parallel, the organisation should consider how to achieve wider adoption of the EA function within the organisation. Ironically, that task is most suited to Business Architects.
Whichever route, there has to be single point at which all designs come together for review. Not necessarily reviewing the designs themselves, but at least the design principles behind them. That review function is the start of a homogenous Enterprise Architecture function.
Moreover, we should concentrate on Business Architecture first where possible. Relying on existing architects is fraught with issues, most of all leading the organisation down a technology-driven path, rather than a business-vision/purpose path as would be more appropriate.
So consider a revised implementation timeline to reflect the earlier presence of Business Architecture, whether within or as a peer to EA.
There are plenty of methods for conducting due diligence, whether for partners, customers, suppliers or mergers. They’re lengthy and they’re expensive. There are times for adopting principles of formal Business Architecture, such as capability matching in M&A situations. But no matter what the deliverables indicate, there’s a useful and quick check to perform as a balance.
I’d like to introduce the quickest method for evaluating a company.
Check the state of the washrooms nearest the directors
Check the state of the washrooms in the middle of the office, e.g. where developers work, where finance work, etc
Compare the two and evaluate according to the 4 box model below
The Simplified View
The simple view consists of a 4-box model with two axis; vertical for the quality of the director/board/exec washrooms and horizontal for the quality of the employee washrooms. That leaves us with 4 quadrants to review:
High quality for director washrooms, high quality for employee washrooms. This the ideal situation. Comfortable for all to work in, with employees respecting their organisation space.
High quality for director washrooms, low quality for employee washrooms. This is a poor situation. It implies one of a few cultural attributes. Either:
the directors think that they are worth more and merit more than the workforce,
the directors do not work closely enough with the workforce (and so do not see the disparity) and/or
the employees don’t care about the quality of the environment (probably resulting from not feeling respected)
Those fall into 2 different categories. The first two fall into whether there is a disparity in provision. The third falls into maintenance and behaviour in an environment.
Low quality for director washrooms, high quality for employee washrooms. I’ve never seen this exist. In all the organisations I’ve work for or consulted for, directors have washrooms of at least equal quality to that of the workforce.
Low quality for director washrooms, low quality for employee washrooms. At least their is parity in these organisations; everyone shares the same facilities. Typically I find these in public sector organisations where money is more importantly spent on providing the services to public rather than on office accommodation.
The More Complex View
The 4-box model gets us to the point of a very quick analysis. But thinking about it further, the relationships are slightly more complex. Hence the revised version:
The revision version uses the same axes as in the 4 box model, but hasn’t been restricted to just the 4 boxes. Instead we’ll take a closer look at the relationships between directors and employee washrooms.
Firstly, the box that related to low quality of director washrooms and high quality of employee washrooms has been extended to a triangle to cover half of the chart. This section, highlighted “Do not exist” relates to any point of the chart where directors have worse quality washrooms than employees.
On the left, we have a basic minimum standard. It’s not an absolute minimum, but one that covers a point at which employees are not being respected.
The top left is similar to that in the 4 box model, again highlighting where directors do not walk in the shoes of the employees.
That then leaves us with a blue area covering an acceptable region. This is the region in which behaviour of the directors matches that of the workforce, with no undue disparity and more a shared “we’re all in this together”. Even with the typical stretched finances of public sector organisations, we should be careful not to stray too far to the left that the lack of care in maintaining washrooms starts to be reflected in the quality of services provided by the workforce.
Despite being British (or perhaps because of being British and very British problems), I couldn’t bring myself to call this the “toilet principle”. It was too disparaging and cast the wrong tone for what I intended. Similarly, the lavatory principle didn’t work. The Bathroom Principle sounded good apart from the ambiguity of bathroom=lavatory or bathroom=room with a bath in. I settled on the Washroom Principle as it should be obvious to all (even those in the United Kingdom) which room I mean.
Expectations can run deeper than you may at first think, especially if those expectations are based on decades of cultural information/misinformation. This may affect attitudes towards quality or acceptance of new ideas, including industry innovations. If we’re aiming to make changes in an organisation, we should look out for the deep-rooted expectations of what’s acceptable.
It’s about the form
High-heels have been a feature of women’s attire for centuries, especially since the latter half of the last century. They’ve become a focus for discussing what’s acceptable in our society, to the extent of legislation in some countries banning companies from requiring its female workforce to wear heels. But also, from a moral perspective about whether wearing them can ever be required. Setting the moral and legal arguments aside, let’s take a quick look at what’s behind them.
Morris conducted an experiment analysing the attractiveness of female gait with the observers having no idea that the women were or were not wearing heels or even that the people they were observing were men or women. The observed were all women, and they all wore flats and heels. The observers had no idea that they’d see the same person’s gait twice; once with heels, once with flats. The result was that the “video clips of the walks in high heels were judged to be significantly more attractive than those in flats”. So there is an characteristic that we find more attractive and that characteristic reveals itself in our perception of gait which high heels enable.
A follow-up experiment reached a further conclusion, summarised as “by exaggerating the normal female gait, high heels serve to falsely enhance our perception of the wearer’s femininity”
So we end up with a cultural expectation of femininity based on the shoe type. Wear flats and you appear less feminine. Wear heels and you accentuate your femininity. And this is whether or not the heels are the most attractive (not just the effect that they have on the wearer) or which footwear would be the functionally most appropriate attire.
Consider a woman walking towards you. If she’s wearing flats, she’d be considered less attractive than if she were wearing heels. But it’s the same woman with the same attributes, same personality, even the same body, but her form and gait is altered by the use of the heels. It’s an expectation and it’s deeply rooted. I’m not saying that it’s the right thing or that women should wear heels, just noting the cultural expectation.
It’s about the tone
Guitarist have for decades sought the tone of the electric guitar pioneers. Think Beatles-era guitar sounds. Those are the tones that act as a reference for all modern guitar tones. Later, Jimi Hendrix took that tone and added colour to it through distorting amplifiers and effects units. Tony Iommi of Black Sabbath took Hendrix’s tone and detuned it. And so on. You can trace the line back to 1950’s popular tones.
Let’s say I innovate and introduce an exceptional guitar amplifier based on amazing audio technology that can clearly reproduce the guitar tone as it’s produced from the guitar. It would fall flat and no-one would buy it. Guitarists are not interested in the best (if we define best as “accurate” to the sound made by the guitar). The reference from the 1950s was made using inefficient amplifiers, inefficient cables, substandard guitars, low technology in strings and speakers that were appalling by today’s hifi standards. Even the speaker in your tv has a better response that those 1950s speakers. But that’s the tone we recognise as good. It’s so deeply ingrained in our models of what counts as good, that more accurate to the guitar doesn’t mean better. In fact the opposite.
There’s an additional complication in that the tone we hear for the guitar isn’t even that 1950s tone from the guitar amps. That produced tone is manipulated at the mixing desk, with appropriate equalisation to filter out the parts of the tone that we don’t need and especially to filter out the parts of the tone that would conflict with other instruments. So if you listen to the isolated tone that’s been recorded, it’s reedy and thin compared to what you’d expect. But add that isolated track into the rest of the song and your brain fills in the gaps.
So when we hear a guitar in a song, we expect it to have a compromised frequency range compared to what the guitar and amplifier can actually produce. If we heard what it could do, then it would sound odd, very odd indeed.
Similar to the high heels, we’ve built up a cultural expectation over decades of what constitutes good. It doesn’t mean it is good and, similar to heels, in many ways it is worse than what can be achieved. But it’s difficult to argue with deep-rooted expectations and, while we know it is possible to change minds, changing something this ingrained will take a lot of effort, time and patience.
As transformation agents (whether directors, analysts, managers, etc), we often miss the cultural expectations. We could use the Empathy Map Canvas, Lewin’s Force-field Analysis, Prosci’s ADKAR or whatever model your organisation chooses to use. But we should be careful as we use each of them, because sometimes the expectations are that ingrained, it’s difficult to bring them to surface. If you were to ask members of the public to attend a focus group on guitar tone and then worked through what’s prompting the change or resisting it, would the concept of the tone from the 1950s actually feature as an arrow that resists change? I doubt it. It’s invisible to them.
Instead, these hidden expectations create a risk to the change programme in potentially blocking the changes for what initially appear to be non-sensical reasons. That is, until you uncover the expectations which run deeper than you first thought.
Now consider the above examples of high-heels and guitar tone. Imagine trying to motivate just the people in your organisation to accept the better alternative (i.e. flats for function regardless of event or a hifi guitar sound). How difficult do you think that would be? And how does that compare to recent significant changes you’ve had to introduce?
As a profession, Business Architects are in danger of becoming defined by just one of the products that they create. Unfortunately, it reduces the value that the profession can provide to organisations and limits expectations of prospects and clients.
What went wrong?
Imagine a fine-dining chef who makes tacos once at the request of a favourite customer. The chef knows tacos will do the job, she knows they’re sustenance, she knows that there are better products and even advises the customer of what she can do instead. But the customer wants tacos, so she delivers.
Other people like tacos as well. So she becomes known as a taco chef and the world is left short one fine-dining chef. Or rather, she’s no longer unavailable to provide the fine-dining experience since she’s now cooking tacos at the request of many customers. She knows she can do more and tries to prompt customers through educating them of other ideas and concepts. But the tacos are pleasing the short-termism of the current customers. It keeps them fed for an hour until they start to feel hungry again. She’s diligent and adds as much nutrition in them as she can. She listens to each customer, understands their needs and can plan a superb meal that will keep them well-nourished for hours. But the customers want tacos and end up hungry again in a hour or so.
The tacos could be cooked by someone on a lower salary. But they may not have her knowledge of nutrition and attention to detail. So yes, they’d still be tacos but not tacos of the quality that she’s been producing.
That’s our taco
And that taco situation is what I see with Business Architects. We’re commonly requested to perform a documentation task, e.g. “document the current business”. It’s usually followed by “so that we can …..”. Look on any job boards for contract Business Architects and you’ll see the activities we’re requested to perform. It’s usually the pattern described above of “document the current business”. Roles for permanent Business Architects are usually wider since clients don’t want professional expertise for just 6 months; they’re thinking longer-term.
The contract clients request knowledge or even certification of TOGAF or Zachman, but you don’t need knowledge of those to be able to document the business.
They may want specific knowledge of their industry sector (e.g. SOX and MiFID II for finance) and they may want experience with specific tools. But if the role requires a Business Architect, then documentation will be the activity.
They may even want knowledge about Business Architecture offerings specific to their industry sector (e.g. MODAF or ETOM). That last element can assist with documentation, especially if there are reusable models in the sector-specific offering.
But in the end, the client is asking for someone to document their current business. There’s often little thought for what to do with the documentation once it’s been produced. Some clients think ahead to wanting a future model, but don’t give much thought as to what to do with the gaps between current and future or how to evaluate benefits of different future models.
That’s our taco. Documenting the current business is the Taco of Business Architecture.
How did we get here?
Let’s take a look at some of the definitions for Business Architecture and then do the same for Enterprise Architecture. We would expect them to be similar, with Business Architecture being more focussed on the business domain.
Business Architecture Definitions
wikipedia: “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
OMG: “defines the structure of the enterprise in terms of its governance structure, business processes, and business information.”
The BA Institute – “defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation.”
The common theme in these is that Business Architecture is referred to by the deliverable or product that it creates. It’s output is the definition of the enterprise business.
Whereas I’d see Business Architecture as an activity. I’d expect to see more relating to its purpose, what it does and why it does it.
Interestingly, TOGAF (also by OMG) describes the context of the first few steps of the ADM with:
“a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).”
TOGAF, in the paragraph above, implies Business Architecture as an activity.
Enterprise Architecture Definitions
Let’s look at definitions for Enterprise Architecture and see if they exhibit the same characteristics.
Wikipedia defines EA as “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy”
MIT CISR defines EA as “the organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.” Jeanne W. Ross, Peter Weill, David C. Robertson
Gartner defines EA”is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes”
Enterprise Architect Body of Knowledges defines EA as “analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology”
Here we see words such as discipline, practice, logic, guide. There’s a mix of nouns and verbs in that list, but they all indicate activity, for instance, you’d only have a discipline if you were to produce something.
We seem to have lost that concept with the Business Architecture definitions, although the TOGAF ADM excerpt does imply that Business Architect involves activity.
The Tao of Business Architecture
I’m going to approach this from a different direction and simplify the concept.
1. Business Architecture assists strategy
Business Architecture only exists because of strategy. Without strategy, Business Architecture has no purpose, no reason for being. We would just be producing documents for the sake of producing documents. Either those documents have to be useful or the process of creating the documents has to be useful, otherwise Business Architecture is a waste in any organisation.
Business Architecture relates to how that strategy is developed and maintained, how that strategy is implemented, how different strategies are evaluated and indeed, even the documentation of current strategy.
A description of the current landscape and challenges
A description of the future target that can respond to those challenges
A plan to get you to that future
For Business Architecture (and also Enterprise Architecture), those concepts make a lot of sense and can be interpreted as:
A description of the current architecture. In this case business architecture, specifically the BMM, organisation units, influencers, partners, governance, etc
A description of the future target. In this case, the goals, outcomes, changes to capabilities, future organisation units
A plan to get you to that future. In this case, the change programme and work packages (most likely later supported by programme and project plans).
Here is the crux. Business Architecture is not only those documents, but it is the activity involved in producing those documents. There is more value in a Business Architect assisting an organisation in defining their strategy, challenging, providing other options, providing analyses, etc than there is in the delivered documents. It is the analysis and the progression of the conversation and the development of knowledge within the enterprise that is of most value. For some clients, the future state doesn’t need to be written down at the end of the assignment because the organisation has developed to the point that all know the common direction. The direction has become subsumed into organisational knowledge and culture. That’s not common, but the fact that it can happen, indicates that we’ve assigned value to the wrong part of the contract.
2. Business Architecture assists the enterprise
When I read the EA definition earlier from the Enterprise Architecture Body of Knowledge, I found that it described Business Architecture with one element missing:
“analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and the use of technology”
The simple addition of “the use of” alters the definition to be suitable for Business Architecture. I also like the focus on “future states” rather than current.
3. Business Architecture assists goals
This is fundamental for me. When I’m explaining to people what I do, I avoid phrases such as “I architect businesses” in the same way that a programme manager may say that “I manage programmes”. Instead I simplify for the layperson and say that:
“I help organisations do what they want to achieve”
and often the first step of that is
“assisting the organisation’s executive define what it wants to achieve.”
From my perspective, the majority of large issues within organisations stem from a lack of alignment. I find that larger organisations evolve to a state of disparate, loosely connected governance models that are not aligned with a central set of themes (or goals in this case). I work to align an enterprise so that it can focus resources on what it want to achieve, briefly (or as briefly as is reasonable) documenting where it is now, developing the future vision and then assisting the executive in steering the company towards that vision.
In short, it boils down to: “What direction do you want to go in? Then let’s define what we need to do to get you there.”
Business Architects need to retake the definition of the profession, in order to move clients and prospects from the Taco of Business Architecture to the Tao of Business Architecture.
This should be done with a focus on Strategy, Enterprise and Alignment and a lesser focus on documentation for the sake of documentation.
And since new technology is developed every month and every year, would we be looking at a Techtechtech sector in a decade?
It’s seems ludicrous to think of it that way and it is indeed ludicrous. The reason it sounds so odd to have a Techtech sector is that we’re allowing ourselves to be focussed on the technology that’s enabling us to replace the older business models.
If you get a nice interface to your banking account and that bank account has a different charging model to the older high street banks, does that make it fintech? According to the hyped world, then yes. But it’s stilll banking. It’s still finance. In reality, the newer entrants are just doing what the incumbents should have been investing in more heavily a few years ago.
In some cases, newer entrants who are smaller are working out how to make a profit without the expectations of having to pay the large salaries of traditional banking, without having to pay large, multiyear leases for high street premises, etc. The main lever they’re using is initially technology, but sometimes it’s other elements of the business model that are being altered. That’s a critical point to realise; it’s not always the technology that is being used as a lever for change.
Let’s take the example of First Direct, the HSBC bank that had no high street branches and regularly received excellent customer satisfactions scores compared to its high-street cousins. Mint, Smile and Egg all followed with variants of similar business models. They had changed one element of the business model. They had focussed on the channel of interaction, forcing a channel shift from face-to-face to telephone (at the time) and online (later when the technology caught up). Everything else (apart from perhaps some of the branding/marketing) was the same as the high-street.
What we’re seeing now is other entrants prepared to look at other components of the business model, such as where the revenue is generated (e.g. subscription versus visible transaction vs bundled transaction cost vs bundled products and so on).
Here’s a simple concept: Take the Business Model Canvas and apply SCAMPER to each section. It’s that easy to generate new ideas and that’s what seems to be happening in every sector.
But this isn’t really fintech. Yes, tech is opening up opportunities and provides the ability to change different elements of the business model that would have been more awkward or at least not cost-effective to change before. But, again, it’s still banking. So let’s just call it finance. The big question for incumbent banks is, rather than relying on their current business working in the future, they’ll have to accept that different models will emerge. And it’s their choice if they want to be delivering those models, enabling others to deliver them on their behalf, or simply be swept away as their market share is eroded by competitors.
Let’s get this straight. I’m not against the concept of Fintech. I’m against the fact that the concept exists separate to the Finance sector (or rather a subset of it). I believe that every sector has a duty to innovate, improve and invent. For sector x, we don’t need xtech.
There’s an additional angle to this which I’ll cover in the next article.
I’ve developed a Partnership Map, designed to help us think about which companies we partner with and why.
With my clients, I’ve often found workshop attendees confused (at least initially) by the term partnership. If you use other well-known tools such as the Business Model Canvas, maybe you’ve encountered similar issues.
We all use the term partnership, but rarely question what we actually mean by it. I usually revert to asking what the partnership entails. If it’s one company paying another for services, is that really partnership?
There are two parts to the target
The Map itself: designed so you can print it large and place your partnering companies on the map
A table of the definition of the tiers. I’ll admit this is a very rough draft, but I thought it better to get it out in the world and improve with collaboration, rather than it just being the product of one person.
How to use it
Work through each of your partnerships and place them according to their sector and tier.
Once all partnerships are on the map, step back to look at them
Evaluate whether that partnership should exist, moved tiers or become a supplier-client relationship. Think of partnerships moving from outside to inside or vice versa, or partnerships being consolidated across sectors.
If a particular partnership is giving cause for concern, then consider using the Partnership Canvas for more in-depth analysis.
This is a first draft; it’s my first attempt at putting down my thoughts into a picture.
There are a few tasks before I’d consider it a first release:
The alignment of the words to the circle isn’t spot-on. I’ll wait to see if the quadrants and sectors change first, before making it neater.
The definitions of the tiers and the actions need more thought
Validate the quadrants – I’m not comfortable with the name Business Capability; it’s a working title
Validate the sectors – Do these need to change, add sectors, merge sectors?
I’m happy to collaborate on it, so get in touch at @alanward and let’s talk.
You may have come across the Kano model before. It’s an analytical technique for understanding what your customers want and, importantly, what they’ve come to expect as required.
I was travelling on a local train last week with a largely empty carriage. I had the choice of seats. I am familiar enough with these carriages to know that there are heating vents in blocks underneath every third row of seats, so I didn’t sit behind one of them. That way my feet would have somewhere to fit.
So I a seat two rows behind.
Then I noticed that my knees didn’t fit. Actually, couldn’t fit. I was seated as far back in the seat as I could go and still my legs could not fit straight in front of me. I had to resort to man-spreading (the shame of it!), not because I wanted to but because simple, basic geometry meant that I wasn’t going to fit in that seat any other way.
Since the carriage was empty, I looked around at the other seats to see if I’d chosen a particular tight space. Unfortunately they were all that size.
I’m pretty average in height, my legs aren’t especially long, so I pity those at 6’5″ who have no chance.
What the train operators have done is increased the number of seats by reducing the space allocated to each seat. This isn’t a new problem, nor is it a new solution. Airlines are famous for reducing the space available to travellers. But it is interesting to many customers transport operators are willing to put on the uncomfortable side of the line. Is it 5%, 10%, 50%?
Now let’s look at the travel experience through the lens afforded to us by the Kano model.
Application of the Kano model
The Kano model depends on asking customers what features they would be happy to have and which features they would be unhappy not to have. You ask the same question for each feature (but separating out the questions). The point being that customers can say they really want something, but wouldn’t complain if it’s not present. Or the converse, where the feature is just expected as part of the product.
Even to the point that they haven’t considered not having the feature. Imagine doors that open automatically in hotels. That could be classed as a delighter in that it makes a difference to the customer’s perception of the product. These are at the top of the chart above the red line. But if you ask if a door is required, then it’s likely to be considered a basic, in that it’s required and expected. These are at the bottom of the chart below the green line.
There is also a performance need running from bottom-left to top-right, in that the better you deliver these features, the happier the customer.
Usually the focus is on delighters becoming basics over time as technology makes it cheaper to deliver those features.
Entertainment on airplanes used to be a delighter. Then it became more standard and has been a basic requirement for a number of years now. We’re seeing a similar transition with wi-fi becoming a basic requirement throughout all stages of travel, whether in taxi, at the airport, on the plane, etc.
The reverse path
However the travel industry also seems to be offering a reverse path of taking features once regarded as basic and turning them into delighter. Unfortunately this path exhibits some discomfort as the basics are provided more cost-effectively each year, until the trend for them reverses.
Let’s consider the local train journey. At some point in the recent past:
Being able to sit down in comfort was a Performance Need (the more comfort, the better)
Being able to sit down, without someone else’s bag or umbrella in your face, was a Basic Need
Being able to travel from A-B on the train was a Basic Need
Being able to travel from A-B on the train on time was a Performance Need
Being able to travel from A-B on the train without having to change trains was a Performance Need
Having access to toilets on the train was a Performance Need
Having access to wi-fi was a Delighter
Yet, the service that I was provided gave me the impression that
Being able to travel from A-B on the train is a Basic Need (no change to this)
Being able to travel from A-B on the train on time is a Performance Need (no change to this)
Being able to travel from A-B on the train without having to change trains is a Performance Need (no change to this)
Being able to sit down, without someone else’s bag or umbrella in your face has become a Delighter (this has changed)
Being able to sit down in comfort has become a Delighter (this has changed)
Having access to toilets on the train is still a Performance Need
Having access to wi-fi is a Performance Need, becoming a Delighter
So at some point in the past, being able to sit down in moderate comfort was a basic requirement. This is where it gets interesting, in the eyes of most customers, that requirement still is a basic need. But we’re seeing a disconnect between the customer perspective and the train operator perspective. And that disconnect is increasing with more cohorts or segments of customers as the space per seat is reducing (i.e. more tall people are being made uncomfortable).
We may see a reverse-reverse change, where comfort becomes a delighter yet again. And following that further on, we could see a pendulum effect as features:
initially start out as Delighters, probably aligned with the Early Adopters
become Basic Needs as the technology and environment to produce them becomes cheaper and more prevalent
then become further down the basic needs as companies ratchet down costs by focussing on the bare minimum of Basic Needs
then swing back to being Delighters as new entrants to the market focus on these features as differentiators
then swing back to Basic Needs as the incumbents either adopt a better quality of Basic Need to combat the new entrants or the new entrants become the new incumbents and start the cycle of focussing on cost and delivering the bare minimum for Basic Needs
As a business architect, I feel like I’m sometimes the black sheep and sometimes the shepherd of the Enterprise Architecture function.
The Black Sheep
1: Uncovering the rationale
I feel like the black sheep because I find myself regularly asking why. Why did you make that decision? Why did you choose that approach? Why caused you to think that way?
I tend to use different, phrasing which is more approachable and open, such as “tell me the story so far. How did we get to where we are now?”, etc. But underneath it all, I’m aiming to understand the motivation behind the changes that are progressing in front of me.
It’s not so much a position of devil’s advocate, more of one of uncovering the rationale behind decisions and evaluating whether that decision is still a valid one. Many long-term programmes are governed against a set of principles which were decided and approved over 18 months before. The world has changed in that time so is it still appropriate to continue with those principles.
2: Focus on business
I also feel like the black sheep because we, as business architects, are rarer than technical architects, solution architects and even enterprise architects. To the point that there may be a team comprising many technical architects and solution architects and I can be the only business architect. I’d guess that, before I arrived, there was no business architect presence.
Unfortunately, I find that those who have come directly from the technology route will have less of grasp on issues and potential solutions within the business domain. That includes the vast majority of enterprise architects I’ve met, even though they’ll be responsible for business architecture as well. Typical enterprise architects lean naturally towards the technology domain. Not all, but most as it’s seen as a promotion route from technical architect. If we have more technical architects, then it’s likely that we’ll see more enterprise architects with a technology background and a technology focus.
I feel like the shepherd since business architecture should come first. Look at TOGAF’s ADM, which architecture element comes first? It’s Business Architecture.
Admittedly, that assumes a linear process from 12 o’clock and progressing clockwise. But for many clients, the initiating event is that a programme requires a technical architect, so they start around Steps C or D on the ADM (if they’re following ADM or similar).
Even before you get to Business Architecture, there’s the process of approving the concepts of enterprise architecture, what it will focus on and how it will be done. It’s that stakeholder management within the preliminary activities that, when you look at the skills involved, align more closely with that of the business architect than of the other architects.
Back to corollary to point 1 above, if we start with a business architect, then the preliminary steps and step B of the TOGAF ADM fall into place. A large chunk of A can be developed by the business architecture, since we’d still want the changes to be focussed on the goals and motives of the business.
From then on, e.g. C onwards, we design the architecture (and subsequent technology decisions) based on the business you want to be, rather than the more typical way of having to hammer an organisation into a technology refit.