3 Ideas from Nick Malik on Design Thinking (#ITEA 2017)

Following the 2017 ITEA conference, I recently reiterated what many of us have known for a while: that traditional architecture and architects are endangered.  I also promised to share some of the great ideas from that conference – practical concepts that you can use right now, and which started to demonstrate how architects can still be relevant and add value.

I’d like to start with ideas from a really valuable talk given by Nick Malik, a 37 year industry veteran who describes himself as a “Vanguard Enterprise Architect, Digital Transformation Strategist, Author, Blogger, and General Troublemaker”, currently Senior “Principal Consultant – Enterprise Architecture” with Infosys.

The subject of Nick’s talk was “Using Design Thinking to Develop your Enterprise Architecture Core Diagram“.  In this post I’ll briefly introduce this key concept as well as some of the other ideas that I wrote down during Nicks talk.

#1 – Actually Understand the problem

The first thing I wrote down was incredibly obvious and shouldn’t need reiteration: taking sufficient time to actually understand the problem.  Nick emphasised bringing people into this process – actually talking to people to really understand what they need, so that we “build solutions that people want to use”.

The quote that came to mind during this bit of the presentation was Eisenhower’s “Plans are nothing, planning is everything.”  Why did I think that?  Well, some people will equate “understanding the problem” with analysis and documentation, where the scale of the analysis and documentation corresponds to the perceived scale and complexity of the problem.

But that’s not what was meant – it’s more around the quality of the discussion, and ensuring that there is real understanding of what the problem is, and what is needed.

In my view, the challenge here for some people (and architects) is that doing this well requires quality interpersonal engagement.  I wonder how often we end-up with solutions that are system-centric rather than people-centric?  I suspect it’s partly due to that fact that some of this stuff is hard – it’s easy to let the technology control you.  But I also think there’s another aspect to it – that some people who are good with systems & tech aren’t always as confident with people, and so the people-centric part loses out.

Interestingly, the design thinking page on wikipedia contrasts design thinking with the scientific method; whilst both approaches use iteration, design thinking consciously “considers the consumer’s emotional state”.  Having quality discussions with people doesn’t necessarily equate to discussing emotional state, but even so, I think that the organic relationship between these concepts is apparent, as is their relevance to arriving at better and more holistic solutions.

So, focus more on having quality engagement with people and taking the time to understand.

#2 – The Core Diagram and Design Thinking

The heart of Nick’s talk was the Core Diagram, and using Design Thinking as a way to developing it.  The crucial idea I took from this was connecting the existing and accepted (although possibly under-utilized) architectural concept (the core diagram) with the “modern” technique (design thinking) which has become somewhat hijacked by a market that is “going digital”.

I say “modern” with the slightly sarcastic quote marks because the roots of design thinking actually go back a long way before it became vogue in the current “digital” era. That said, “digital” is relevant to architects because it’s the current language of business, and those not conversant in it risk being marginalised, regardless of what people think digital means.

Before I go too much further I just want to point out that I am new to the concept of the core diagram – at least regarding the specifics of the concept as Nick describes it.  My goal here is simply to help spread the word on this as a idea, because I think it has value.

Nick has been writing about core diagrams for some time (circa 2012), and I wonder how much the approach to developing them have changed?  I haven’t yet properly read and digested the original approach, but it’s now 2017 and Nick is connecting the development of core diagrams with design thinking – I’m not sure whether this represents a fundamental shift in the approach, or a natural evolution that recognizes shared principles that were always inherently there.

The reason I mention this is that if you go searching online you’re going to find articles from a few years ago (c’mon, 2012 isn’t that long ago) , and you might (incorrectly) feel compelled to dismiss them out-of-hand as not being contemporary and not solidly connected to “design thinking” as is currently vogue.

So, what’s a core diagram?

As with a lot of good ideas the key concept is relatively simple, according to Jeanne Ross (Director, MIT CISR):

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation.”

The bold is mine.  Nick included this quote in his deck – having taken it from an email Jeanne sent him in 2011.  Nick described it as “the best advice we all ignored”.

Actually Nick, I think I might have a tongue-in-cheek explanation for that – there’s currently no wikipedia page for Core Diagram 😛

Jeanne describes it as:

“a simple one-page view of the processes, data, and technologies constituting the desired foundation for execution.”

One-page is key.  What you’re after is something that everyone wants to put up on the wall, in their office or the teams shared space.  You want it to support a wide range of discussions and thinking across all your stakeholders – especially those who are responsible for, or have a lot of influence over, the end result.

Here’s some links for you:

  • Enterprise Architecture As Strategy” by Jeanne W. Ross, Peter Weill and David Robertson, on Amazon.
  • What is a core diagram?” MSDN blog post by Nick Malik, 2012.
  • (Slides from) Open Group Presentation on MSBI method of creating Enterprise Architecture Core Diagrams on slideShare, 2012.

A Brief aside info Marketecture

As Nick was describing the core diagram I couldn’t help but mentally connect it with Marketecture and effective marketecture diagrams.  In Nick’s view they aren’t the same thing, and I can see why he says that – but it’s subtle, multi-dimensional, and I’m still thinking about it.

I’ve previously found a number of useful definitions that help capture what I think marketecture is (which I sketch out in “Appendix: The Mysteries of Marketecture” in this post).  In summary it’s:

a business perspective, including concepts such as licensing, the business model and technical details relevant to the customer; it can also serve as an informal depiction of the systems structure, interactions and relationships that espouse the philosophy behind the architecture.

We had a very brief discussion whilst walking out at the break, Nick’s view was (and assuming my recall is accurate) that marketecture is designed to assist the “sale” of the solution, with the underlying implication that relates to the “transactional” nature of the sale; where as “you can take a core diagram to governance meetings”.

I guess it depends on what is meant by “sale” – there’s the commercial sense i.e. trying to sell faster processors to end users, but there’s also the idea of “selling” a solution as being viable to executives and governance bodies.  From a philosophical stand-point I think good marketecture and core diagrams have that in common.  There’s no doubt a lot more to explore here.

 

#3 – Ideation Techniques

Design thinking, and the concept of rapidly coming up with ideas deserves more time and space than I can give it here, so to get you started, let me just give you a couple of the ideas Nick shared:

  • Reverse Brainstorming – Instead of asking, “How do I prevent this problem?” ask, “How could I cause the problem?”  The idea is that by initially focusing more on the problem you’re then better equipped to start considering solutions.  It reminds me of the 37 Signals piece called “Have an Enemy”: “Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.
  • SCAMPER – an acronym of activity based thinking process which help you think out of the box: Substitute, Combine, and so on.  It’s been around since 1953.

 

#ArchitectureInTransformation

Is the Tide Turning? #ArchitectureInTransformation

Good news, I think, from the 2017 IT & Enterprise Architecture Conference, which I attended earlier this week.  As is well known, “Traditional” architecture, and Enterprise Architecture in general, has been on the endangered list for a while now – but I’m starting to see really positive signs that (some) architects are bouncing back and starting to successfully adapt.

In due course, I’ll share some of the many notes and great ideas I captured during the event, but before I do I just wanted to quickly preface the whole thing with this overarching theme (that architects are starting to adapt) – because it was a theme that permeated much of the conferences content – and from what I could see these ideas were generally being embraced by the attendees – but it’s still very early days…

So what are these magical signs?

#1 – Attitudes

It was clear from the architects I spoke with that they recognised the need to adapt, have a positive attitude about doing so, and are on that journey.

#2 – Platform as a Product

One of the clearest signals was from Mike Nooney, who shared with us how Air New Zealand are developing their platform strategy.  A key takeaway here was “platform as product”, in other words, start thinking about your organisations platform and systems as a product (and everything that mental-model entails).

Of course it’s a non-trivial exercise – there’s lots of deep and subtle implications in the statement.  I’ll be looking into this more (a lot more, I’m sure), but for now I suggest you start by thinking about what good products are and how they come into being – i.e. “it’s not just about technology”; thinking about the entire ecosystem: end-users, API-users, support, marketing (and so on); and how you’d actually work with the other human beings across that entire ecosystem to make it happen.

It’s worth noting that there’s a spectrum here; in some circumstances you might simply get away with (or start with) a simply terminology change: “(Digital) Platform” instead of “EA”, although obviously a deeper change is likely to be needed at some point.

#3 – Embracing ‘new’ techniques, such as Design Thinking

Design thinking is one of several approaches that have been gaining serious traction in recent years.  Sure, some of the core concepts inside some of these approaches are not necessarily new, but they’ve reached a level of maturity and market presence that means ignoring them isn’t wise.

There’s this fuzzy nexus of concepts – Digital is one, taking a (platform as) product centric view is another – think of it as the new/emerging paradigm for how the mainstream now conceptualises systems.  Design thinking, and related approaches, are a part of that paradigm.

The good news for architects is that, as mentioned above, the core stuff inside these approaches isn’t necessarily new – it’s stuff that as architects we kinda mentally do already, so the leap isn’t as big as it looks.

Positive evidence of architects taking this sort of approach on was visible in several presentations beyond Mike’s:

  1. Nick Malik emphasised the importance of gaining a deep understanding of the problem, and whilst he didn’t refer to design thinking directly I found it to be a pretty easy mental leap from his advice to leveraging design thinking as one of the ways of getting there.  Update – as per Nick’s comment below, design thinking was a focus of his talk – my memory here isn’t quite as accurate as I’d like it to be (thanks for correcting me).  I’ll share more on this in due course, including links to where you can get Nick’s thoughts first hand.
  2. Nick also made reference to several books including “Stories that Move Mountains: Storytelling and Visual Design for Persuasive Presentations” – and whilst this isn’t billed as “design thinking”, (as a newbie) I can see some parallels.
  3. Blair Loveday did a whole session on design thinking – the fact that this even happened is itself an indication of how things are moving in architecture circles.
  4. Chris Tuohy spoke about his experiences with Agile and culture change at Westpac – design thinking was explicitly called out as being part of their approach.

So whilst “traditional” architecture may be dying, I’d think the good bits from that legacy will continue – with some new additions and perhaps adapted a little in terms of tactics and approach.  When you realise that such a major transformation is slowly happening right before your very eyes, and that you’re part of it – that’s pretty cool.

#ITEA – https://www.conferenz.co.nz/events/it-enterprise-architecture

 

Are traditional architecture engagement models still relevant?

An article I wrote, originally posted on the Davanti Consulting website, 30th November 2016, reposted here with permission.

Reinvention dominates the business landscape, pervading how we work and how we engage with those around us. As an architect, I sometimes wonder how many of my industry colleagues have noticed this and contemplated similar innovation. As architects we are often perceived as dinosaurs; surely then, the time to start reintegrating ourselves is now.

THE CURRENT STATE OF ARCHITECTURAL ENGAGEMENT

A good architect can bring excellent value, but that value is lost if it arrives too late. Some of the barriers to this value even appear to be systemic or stem from entrenched legacy thinking.

The way in which architects engage is influenced by several factors, including:

  • Control: architectural governance is often perceived as regulatory rather than wisdom.
  • Processes: these are often complex, “heavy”, unwieldy and time-consuming.
  • Resourcing: architectural capability is often scarce, a scarcity which is exacerbated by heavy processes.

Traditional architectural engagement tends to be based on a “these are the rules” approach renown for volumes of documentation and thinking before any real work starts. Interestingly this way of working doesn’t really have a name – it “just is”. There’s definitely a number of architects who got the Agile memo, but overall that percentage is still relatively small.

There are architecture frameworks such as TOGAF, but a framework is not an engagement model. TOGAF has the “Request for Architecture Work” concept, but this is more of a one-shot form. TOGAF is aimed at enterprise architecture and whilst it refers to solution architecture it does not attempt to address how architects should engage with stakeholders in a product or project delivery setting.

At the project level, architectural engagement will ideally be in the form of an embedded solution architect. Ideally their engagement will start with the business case and continue through to overseeing the implementation. At worst, their involvement will be sporadic or non-existent. For various reasons such as a scarcity of architects, coupled with the weightiness of architecture processes, this engagement will likely be forgone for smaller projects. The associated risk is that smaller projects often grow into bigger ones, consequently attracting belated architectural attention.

So, short of everyone drinking the agile Kool-Aid what should we do? What might a revamped engagement model look like? How do we start, and what are the challenges we need to solve?

FUTURE STATE

The goal is to ensure that architects are able to add value in a timely and sustainable manner.

As architects often work as part of an architectural practice, and within the boundaries of architectural governance, both the architecture practice and governance may need to be revamped:

  • The architecture practice should reinforce behaviours and processes that make the team more consistent in their approach, allows them to support each other, and thus positions the team to offer a more consistent experience to their business clients.
  • Ideally architectural governance should support the team in this change as they are its ambassadors. Governance should not be about doing architecture for the benefit of the architect.

At a high level, think about making these changes so that the following value is unlocked:

Do this 

 So that

Revamp governance.
  • It provides supportive guidance, rather than be a place where things go to be vetoed.
  • It is easy and relatively painless to use, and therefore gets used more often.
Create a toolbox of processes, tools & artefacts that is accessible.
  • Non-architects find it easier to understand and use, as a result the architects will need to spend explaining it.
  • More time can be devoted unlocking value and less time given to discussing the process.
  • Architects have the time (and opportunity) to spend engaging more broadly and more regularly with the business.
Encourage architectural mentoring and coaching.
  •  Architects can be seen more as collaborators and supporters.

 

REVAMPING GOVERNANCE

This isn’t a wholesale re-write, but more of a health check and possible diet.  You might be familiar with the concept of a good value proposition being one that your grandmother could understand; check your architectural governance processes and make sure they can pass that test. Make sure that what is expected is very clear, not onerous, and that its business value is self-evident.

CREATE A TOOLBOX OF PROCESSES, TOOLS & ARTEFACTS THAT IS ACCESSIBLE

Empowering the business, whilst keeping them and the architect team aligned, is going to mean having some supporting materials available. These will work with the revamped governance and be very practical in nature. In situations where architects are working with the business in a mentoring context they will need materials that they can refer the business too, and which the business can use with a degree of self-reliance. These materials should outline:

  • Technology constraints that are deemed important, and why. If possible, a sense of direction, as business and architecture are seldom static.
  • What questions to ask themselves, and when, so that the business doesn’t paint themselves into a corner.
  • Areas of danger or concern; things they should escalate to the architect so that they can be appropriately supported. Thinking along the lines of RACI can be helpful – for example: when should they inform and when should they consult.

These material might be pre-written guides, checklists and (lightweight) documentation and diagrams, or, checklists that the business progressively complete with varying degrees of assistance from an architect. They might be anything from risk assessments, solution option assessments to solution architecture definitions.

Creating materials that effectively support the business (and the architects) means creating materials that are easy to access – not just in terms of being easily located, but also easy to read, and understand.Materials should be suitably light-weight, so that they are easy to consume and keep up to date. After all there’s no point freeing up an architect’s time just to write more documents.

In terms of the artefacts you expect the business/projects to deliver, ask yourself “who will read the documents”? If the answer is “only other architects” then exactly what value does it provide and is it really necessary?

ENCOURAGE MENTORING AND COACHING

There will always be a need for architects to do the architecture, and to be deeply embedded in a given project; but conversely there are many opportunities where a lighter touch may be equally effective.

Coming to the business with a mentoring approach places everyone on a more equal footing, and increases the chance of a more meaningful collaboration. The architects are close enough to spot potential issues, establish some sort of rapport with the business and lead them where appropriate. The business is free to do some of the heavy lifting themselves, freeing up some of the architect’s time.

If successful, architectural value should become easier to unlock, and more valued by everyone.

ENGAGEMENT STYLE

So far we’ve focused on the engagement model, i.e. elements of structure, broad approach and the rationale behind it. Hand-in-glove with those concepts is the style of engagement, i.e. the communication style used and how you relate to stakeholders on a personal level.

It is vital that you tune-in to your audience. Architects need to be leaders, they need to manage stakeholders of all types, and in a range of different situations. To do this effectively will require you to adjust your engagement style to suit both the audience and the message.

The best laid plans are easily ruined by poor execution, and as good architecture is dependent on good communication it is essential to get this right.  Effective communication is a substantive topic in its own right, and beyond the scope of this article, but to get started, consider:

  • Being available, approachable and responsive.
  • Being good at active listening.
  • Being able to relate to others.
  • Being able to simplify the complex.
  • Being able to speak up.
  • Being good at asking questions.
  • Being effective at persuasion, mediation, facilitation.
  • How to say no without coming across as (or actually being) a roadblock.
  • Picking the right communication style for the audience.

IN CLOSING

As a discipline architecture offers great value, and architects tend to be clever people, but realising that value is not straightforward – as architects we need to be proactive, we need to be mindful of changing expectations as the world changes around us. Just because architecture deals in the fundamental does not mean it is impervious to change.

As practitioners of architecture, take what you can from new ways of working, such as Agile and collaborative tools.

Show the business and the rest of IT that architecture is not something up an ivory tower, and that we can lead innovation and change by example.

Career Progression into Architecture

In terms of career progression into architecture, people typically start off from one of several common “starting positions”. For example, a solution architect or application architect this is likely to come from a software development background.
Here a map of some of the more common paths:

typical-career-progressionThere are more types of architect and pathways than what’s depicted here, but based on conversations with architects I have met (or interviewed) this is a fairly accurate summary of some of the more common paths.

The Architectural Role Meta-Model

For simplicity, I define it in three parts (outlined below). In broad terms, Enterprise and Solution architecture disciplines cover the full range of domains but operate within a specific level of abstraction; whereas Domain architects cover all levels of abstraction but within a specific domain.  An in-depth write up on this can be found here, but in summary:

  1. Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
  2. Solution Architects – who typically operate at a project or programme level. Although solution architecture covers the full breadth of domains, an individual solution architect will typically be relatively narrow in their focus – either providing general technical leadership within the scope of a specific project, technology or domain.
  3. Domain Architects – typically operate simultaneously across the spectrum of enterprise and solution architecture, but within a single specific domain. They will support both enterprise and solution/delivery specific needs.

Progression

We typically see common paths into and through architecture, such as the software developer into the application or solution architecture space; business analysis into the business architecture space, and so on.  Once in the architecture space it is possible to side-step into related roles – this might be done as a conscious and fundamental career choice, or may simply represent shorter-term variety driven by the work available.
The progression from solution architecture to domain architect to enterprise architect is common but by no means the only career path.

To a certain extent there’s a drift upwards in terms of abstraction (developer to solution architect; solution architect to domain or enterprise architect), but this isn’t always strictly the case.  It’s fair to say that each role has a set of skills and a temperament that suit it – some people will mature from one role into the next, others will take an alternate path.

The Product Specialist

One of the assumptions behind the solution, domain and enterprise architect roles is that these people often have a breadth of experience that goes beyond a single product or technology stack.  In other words, their careers are not defined along narrow vendor specific lines.  This is largely borne out by what I have seen in the market in terms of the experience people have and the career paths they have taken.

Such specialists will be genuinely skilled at what they do but lacking breadth of vision and depth of understanding that someone with a more diverse background is likely to have.

Is this good or bad?  Well I think that depends on what you need for the problem at hand; sometimes you need a very specialized tool for a very special problem, whilst other-times a more flexible tool is best.

One thing to be sure of though, as the technology market grows in breadth and diversity, areas of specialization will deepen.  As anyone familiar with web development in the early 2000’s can tell you, the number of stacks and architectures available has grown considerably; as that range increases so does the potential for individuals to specialize; so does the possible combinations of skills a specific job description might call for.

This specialization is reflected in the vendor space where larger vendors have their own subset of roles (think marketecture) that mirror the role hierarchies found in the general market. We therefore have product specialist roles starting to emerge, with people operating at the level of a solution architect but with a background that cannot assumed to be as broad as those from a more general background.

 

The Layman’s Guide to IT Architecture Roles

Most roles within information technology are fairly well understood and defined but this can’t always be said of architects.  This can be a problem for anyone considering a career progression into architecture – exactly what are the options and how do you get there?

Here’s my view on what the architecture roles are that you’ll typically see in today’s market, and how you might progress to them.

How to define architecture roles

There’s two ways we can define architecture roles…

The first concept I want to clarify is that of the domain.  An architectural domain is simply a conceptual area within the wider IT / architecture landscape, for example: infrastructure, applications, data, security and so on.  These domains are essentially areas within IT and architecture just as disciplines such as cardiology and neurology are areas within medical science.

A simple way of understanding architecture roles is to consider them against these domains, specifically in terms of breath and depth:

  • Breadth – how many domains the role covers.
  • Depth – at what level of detail does the role typically operate.

structure-of-architecture-roles-breath-and-depth

Please note this is not a definitive list of all architecture domains.

The second way we can classify architecture roles is by placing them on a marketecture-tarchitecture spectrum.   In the simplest possible sense:

  • Tarchitecture (technical architecture) – deals with the actual components a solution is made up of, how it will actually work and how that technology is managed.
  • Marketecture – (a portmanteau of the words marketing and architecture) typically deals with views of the solution that are more readily understood by laypeople, and tend to focus on non-technical aspects. There are 2 or 3 different definitions of marketecture but the exact differences are not critical for an introductory understanding to architecture roles; see the end of the article for more information.

It would be correct to assume that there’s often tension between these two perspectives, however, it would be wrong to blindly assume that all marketecture is inherently evil and adds no value.

Architecture roles and how to classify them

In my world view, there are three broad types of architecture work:

  1. Enterprise Architecture
  2. Domain Architecture
  3. Solution Architecture

I want to call out these three because they account for the majority of architecture work out in the market, even if the person doing the work has a job title that sounds different.  In addition to these there’s a few outliers that are organically linked to these but which aren’t your classic architect role, or which defy the classifications I’m using here.  Let’s ignore those for now.

structure-of-architecture-roles-3-broad-examplesNote, the basis of this diagram isn’t necessarily new and it might be something you’ve seen before.

What about the whitespace between enterprise and solution architecture?  Diagrammatically the whitespace exists to make the diagram easier to interpret, however, in the real world the exact point at which one ends and the other begins will vary from one organisation to another, partially based on what work needs to be done and the people available to do it.   In simple terms though, solution architects tend to focus on project specific work, enterprise architects do not.

We’re now at the point of fundamentally understanding the difference between architecture roles (please forgive the role descriptions which aim to give an idea of what the role is about in less than 30 words).

Role Description Relative Breadth and Depth Marketecture – Tarchitecture
Enterprise Architect Strategic, high level analysis and architecture across the entire organisation. Broad, high level 90/10
Application Architect Strategic, high level analysis and architecture within the given domain, plus supporting delivery / project work. Narrow, all levels 50/50
Business Architect Narrow, all levels 50/50
Data Architect Narrow, all levels 50/50
Infrastructure Architect Narrow, all levels 50/50
Integration Architect Narrow, all levels 50/50
Network Architect Narrow, all levels 50/50
Security Architect Narrow, all levels 50/50
Solution Architect Analysis, architecture and design for a specific project. Broad, low level 10/90

Please note that the roles listed above is not definitive, you’ll frequently come across variations to these.  How I suggest you understand those variations is to start by understanding the concepts described above, and then figure out where those variations sit in that context.

A further word on Solution Architecture

It’s important to remember that for solution architecture, although in definition the scope of the role is broad, the practical scope of the role in terms of a specific project is relatively constrained.  This is why the term solution architect has such broad usage, and why many people struggle to accurately define it.

Consider this hypothetical example:

structure-of-architecture-roles-solution-architect-example

For this hypothetical project, the “scope” of the domains that the solution architect is dealing with is heavily focused on the application domain, with a notable amount of security work and a bit of data and infrastructure thrown in.  The point is that whilst the level of “depth” they will be working at will usually be relatively consistent, the pieces of the “breadth” they focus on will vary greatly.

The exact mix of domains that the solution architect will cover on a given project will depend entirely on several factors, such as the what the project is trying to achieve and what other skills are available to support the project.  Consider the example above; if the organisation has dedicated infrastructure and data architects then the relative effort the solution architect is likely to spend on those domains is much less than if the organisation does not have infrastructure and data architects.

Appendix: The Mysteries of Marketecture

There are a number of definitions of what marketecture is, the three below being the most relevant; you might find that in a given your specific context what marketecture means is a hazy combination of these:

  1. The Hohmann / Fowler view: the business perspective of a systems architecture, including concepts such as licensing, the business model, technical details relevant to the customer (i.e. not necessarily ‘real’ ones). Brand elements, and so on.
  2. The Ian Gorton view: an informal depiction of the systems structure, interactions and relationships, possibly augmented by labels that espouse the philosophy behind the architecture.
  3. The Urban Dictionary view: a fairly cynical view in which the architecture is dreamed up by the marketing department and has little to do with reality.

Done properly, marketecture should fall into definitions 1 & 2, and serve as an excellent support to stakeholder discussions throughout the life-cycle of solution development.

Further reading on Marketecture: