Chaos Based

Seemingly random...the evolution from chaos to complexity

2010-12-14T13:12:00.002-08:00

Today, in discussing with a client, my approach to enterprise architecture and the application of chaos theory, he asked me what I see as the difference between complex systems and chaotic systems.

This made me think that it is probably worth looking at why I see them as different and what the relationship is between the two. Both are dynamic in nature, but in the one there is a defined structure based on knowledge of all components and factors, the other however…

For me (and most sources seem to agree with me) the difference between dynamic complex systems and chaotic systems is that in a chaotic system all the attributes, components and deterministic behaviours are not 100% known or model able.

In the complex dynamic system, the components are all known and all their attributes, behaviours and relationships understood and modelled.

The random or rather, the unknown and not-understood/undefined nature in ecosystems lends all ecosystems (and Enterprise architectures) to really be chaotic, even where it is believed to be optimal (within a contained scope).

The true understanding and definitive structure (relation) can only be defined for what is clearly known and contextualised - the moment there is one change that was not previously known of, then the complex dynamic system migrates to a chaotic system.

In considering that Chaos theory centres on "random" deterministic behaviour, I believe (and it is a belief, rather than having absolute proof) that behaviour can really only be defined as seemingly chaotic/random, because of the lack of understanding or context. This random behaviour can however become known and understood (even modelled) over time or from the right perspective, providing potentially for returning a chaotic system to a complex dynamic system.

Complex dynamic systems are really just snap-shots or contained extractions from chaotic systems (or the greater ecosystem) – ultimately everything in the universe has an influence on anything else (however minute).

To bring this back to Enterprise Architecture – my function should be to provide an organisation with the view (plus change analysis and governance) of the current (or future state) dynamic complex system (basically the contained structure within the chaos), but also to work on resolving and moving from a chaotic system when an unknown change/factor comes into play.

Chaos Theory applied in project environments

2010-08-14T18:13:00.000-07:00

Today I discovered, what is one of the closest related approaches in applying Chaos Theory to a business, as what my focus is around the application and value of applied chaos theory to the Enterprise Architecture function (and business in general).

Randy England, published and article titled "Applying Chaos Theory in a Project Based Organization" (based on his presentation to the PMI Global Congress 2009 EMEA).

The essence of the article is that most people think of Chaos and immediately make a negative connotation, rather than to try to understand and exploit the benefits of an dynamic and deterministic ecosystem that is a business. With the focus on projects within organisations, Randy indicates, that there is huge benefit in uncovering latent capabilities as well as unidentified factors, highlighting the need to manage projects through active collaboration and focus on a shared purpose. He highlights that there is therefore a far greater need for communicating effectively and working closely with all influencer (in this context the people in an organisation) with an effort on influencing them through intervention at the right points. To do so it is important to uncover the factors that could drive and/or restrain activities toward project goals, and to focus on utilising positive but to manage the potentially negative forces (not just limited to the project, but based on wider impacts) - this in my approach is a core component of the Enterprise Architecture function as part of change management (in programmes and projects).

Since I use the business ecosystem concept actively, both in enterprise architecture consulting and in the intelligence embedded in Confluxes, this statement held a lot of value for me - "View people and the organization as an integrated part of a natural living system, subject to ambiguities and chaos, and capable of coalescing forces into powerful outcomes"

This was the first time that I come across the work of Randy Englund, but it will not be the last. With an approach and view that is so closely linked to my own use of Chaos Theory, I will keep closer track of information coming from him.

Only the tip of the iceberg

2010-08-13T16:21:00.000-07:00

I'm currently doing some work on profiling businesses (their products, requirements, customers, suppliers and partners) to contextualize them within the greater business ecosystem. This is to support both my PhD research work (in applied chaos theory to enterprise architecture in relation to business change management) and to further refine the intelligence models for Confluxes (currently a closed network, but with final touches being put on for public launch as a web based service).

In this task I use the model and intelligence embedded in Confluxes to uncover the existing inter-business relationships (B2B customers, partners and suppliers) as well as to the links between the relevant businesses (products and procurement requirements), leading to some very interesting results with regards to how and which businesses intersect on various value chains.

This lead me to discover a a service called Iceberg (by Fractis Ltd), an easy to use software as a service for creating workflow and web applications. The solution aims to enable users to use the web based service (or on premise solution) to create integrated workflow for weaving together enterprise solutions - no code writing required....unfortunately this send my mind running, especially around the name of the solution - Iceberg.

Having dived deep in the oceanic trenches that is the enterprise operational and technology landscape (not even thinking of the wider business ecosystem context beyond the boundaries of a single business), I have been fortunate (because I survived the ordeals) to uncover that the solutions being addressed are usually only the tip of the iceberg, and have little chance of noticing that there are also other iceberg tips attached to the same base.

I'm all for solutions that reduce complexity and empowers the business user, but this leaves a huge opportunity for activity in isolation to creep in, really disrupting (or even destroying) the carefully crafted architecture that supports the interlinked technologies, data and functions that exists in a business.

This is by no means a critique on the Iceberg service, but purely an observation in relation to the use of software as a service or really any software/technology/process implemented on site, but in isolation with out factoring the impact beyond its immediate reaches.

I have to admit, I have not been able to put the Iceberg service to the test, so it might just make me eat my words of warning, if it does have safeguards in place to guide users to consider the wider context (which is especially important when you deal with creating enterprise workflow and solutions!) - From the surface and the testimonials, Iceberg looks like a good tool...in the right hands and carefully used as guided by a competent enterprise architecture function.

I'm a big supporter of Software as a Service (SaaS), Confluxes is really a SaaS solution (targeted at micro, small and medium businesses), that through understanding a business context within the greater business ecosystem, can then automatically discover new business to a business, as well as to find (and compare) potential suppliers for the business' requirements (plus the supporting interaction management and market information tools to support this). Confluxes, after launch, will also open the platform to other software providers to deliver their solutions through the platform to the business ecosystem and can integrate with the functions and information from Confluxes, thereby driving more SaaS solutions to the market.

While we may be implementing (and me working on improving) the intelligence in Confluxes to be able to apply chaos theory for the discovery of opportunities, and to use system complexity and relational dynamics to understand a specific business context to the greater business ecosystem - it is still a far way off from being able to have an AI like enterprise architecture function for managing the use of software (and processes, organisational design, infrastructure, etc.) as it is purchased, implemented and used inside a business at a far more granular level...with far more minute and seemingly unrelated impacts.

To ensure that SaaS solutions (and other buzz items like "Cloud Computing" - nothing other than virtual infrastructure really!) actually deliver benefits to the business as a whole (and not duplicate or negatively impact somewhere else), you will need an EA function to govern it.

Service Orientated Architecture - not just a technology perspective

2010-02-23T04:54:00.000-08:00

Service Orientated Architecture (SOA), as with most references to Enterprise Architecture, seems to technology focused, rather than an all encompassing architectural approach covering and cross-integrating between the domains of business, applications, information and infrastructure (think of the value of SOA relevant to process, people and technology).

Having just read a few comments on a Linkedin discussion around SOA, the feeling I get is that the approach of SOA is still dominated (and hijacked) by IT and development, rather than to include the considerable benefit of a holistic, business and technology approach in the utilisation of SOA.

Admittedly the origins of SOA sits in systems design principals for development and integration to facilitate the multiple applications of services, but it is of vital that the actual business operational processes and structure requires/support the reusability of functionality or information.
In this context, the Service orientated architecture fits very well in the business design where the business operational architecture utilises the same theoretical approach as the classic software based SOA. In fact, the two poles can actually be drawn significantly closer when the technology SOA side mirrors the business SOA side and then draw the application lines through the linking of the relevant information (irrespective of the technology interface be it xml or a web service based exchange).

In business redesign and process optimisation, the application of SOA is actually very prevalent - most of these change activities are centred around reduction of duplication, simplification of processes and the specific reuse of information and activities, thereby reducing the actual operational load while ensuring that all functions are executed effectively. It is with this in mind that I approach both the technology and business architecture from an integrated SOA, where business (people and process) is the dictator of the technology requirements (technology is just a resource, though of high value to enable optimal business function...some times even to drive optimisation) and the application, information and infrastructure architecture is designed to ensure that it effectively and efficiently support the business operational needs - creating the mirror SOA for a holistic Enterprise Architecture.

LEGO - the easy way to explain server virtualisation

2010-01-11T07:56:00.000-08:00

I stumbled on this very cool and simple explanation of server virtualisation using LEGO...while browsing through the archives of one of my favourite blogs, Brick Brothers.

I have previously mentioned my love for LEGO and that I have used it for work purposes as well, but this must be one of the best uses of LEGO to demonstrate something business related.

Even though my work focus mainly on the strategic architecture of entire organisations (business, operational and integration approaches during change), the technical Enterprise Architecture/infrastructure questions around virtualisation are frequently asked. I don't think I can explain it any better (or easier).

BlueLock, thanks for helping me answer this topic in the future, and Brick Brothers for providing such a cool view on LEGO use.

Note - I'm not endorsing BlueLock, the company behind the video using Lego to explain server virtualisation. I take a merchant/provider independent approach in all my engagements, focusing on the most appropriate and viable solutions for the specific customer, while considering all known external and internal factors during the change.

Confluxes - the business ecosystem in perspective

2009-12-09T04:58:00.000-08:00

On Saturday we, opend Confluxes for businesses all over the world after a period of running the service only on a closed network for a few hundered businesses.
Confluxes is still in Beta, but have already had a number of business registering them selves and definign their business relationships, products/services and requirements.
Over then coming weeks Confluxes will see a transformation that will greatly add to a smooth user experience and intuitive interaction...as well as to improve the look and feel of the service that is currently in Beta.

Confluxes (plural of Conflux), as the name indicates, is the point where business come together from various value chains to create an exponentially expanding value network, where through collaboration the individual businesses can achieve far greater success within the business ecosystem.

"Buy, sell, collaborate…businesses are part of an ever evolving ecosystem. Each business has an influence on others and business can’t exist in isolation."
Confluxes empowers businesses to work better together in achieving greater success in the business ecosystem

Confluxes is focused on small/medium businesses, to provide an effective platform for them to drive market inter action, by factoring their unique business context in an ever expanding and dynamic value network.

The Objective behind Confluxes is to create an extensive and dynamic business ecosystem platform to drive effective opportunity and solution discovery for small/medium businesses, and to enable inter-business collaboration.

One of the key enablers of the Confluxes platform is the applied intelligence within a multi dimensional network that can accurately profile and contextualise a business within the greater value network.

Confluxes aggregates diverse bits of information and uses a bit of AI (a combination of applied chaos theory, combinatorial optimisation and complexity analysis) to contextualise a business in relation to the greater business ecosystem and to also weave their extended value network reach based on the specific business' customers, suppliers and partners. A business defines itself by confirming their relationship with other businesses already registered on (Confluxes intuitively identify potential duplications) the value network platform or by inviting their customers/suppliers/partners to register on Confluxes and confirm the relevant relationship.
All these relationship connections and the extended reach through the value network, and businesses' specific products/services and requirements (and the various platform integrated communication, collaboration and transaction tools) creates thee dynamic and intelligent business ecosystem.

Confluxes uses a business' unique perspective on the business ecosystem to provide market intelligence, discover relevant opportunities, identify appropriate suppliers/providers and facilitate inter business collaboration.

The key benefits of Confluxes are:

Effective and automated business opportunity discovery
Efficient and accurate solution and provider identification
Drives and facilitates inter-business collaboration
Exponentially expands a business’ reach and market exposure within the greater value network

Take advantage of getting in on the platform at an early stage, register and start building your value network and benefit from truly using the business ecosystem.

Is Business a Zero-Sum Game?

2009-11-26T22:31:00.000-08:00

A Zero-Sum game is a situation where there is no 'win-win' possibility, where whatever a party/player gains is matched by a commensurate loss by other players, so it always comes out even.

As Wikipedia puts it:
"If the total gains of the participants are added up, and the total losses are subtracted, they will sum to zero. Zero-sum can be thought of more generally as constant sum where the benefits and losses to all players sum to the same value of money (or utility). Cutting a cake is zero- or constant-sum, because taking a larger piece reduces the amount of cake available for others."

Like any ecosystem, the various players (creatures or business entities) will each strive to do the best for it self. This demands that ultimately another player (not necessarily directly connected) will experience an impact that is detrimental to them on a whole (from an out side view), but this required to sustain the entire ecosystem.

In my oppinion, it is not really a zero-sum game, but rather a game of the fittest will survive and those that want to succeed will have to evolve to ensure that they also thrive (or survive) in a competitive and changing environment.

The business ecosystem also follows chaos theory (where there is order in the apparent chaos), system dynamics and entities will/must display self determination.
In the business value network there will always be business that lose out on a opportunity to another bidder, but this either ensure that the better business survive or thrive – except where there is lack of intelligence, clarity of market demands and opportunity, or subjective business behaviour (such as collusion or nepotism – all which will ultimately be to the detriment of those involved) – so where perspective based insight, objectivity and evidence base decision making is used, the negatives should be encountered in another area.

All this stated, each business (and creature in an ecosystem) will at some point need to experience a negative exchange as part of a zero-sum game in a specific ecosystem.

It isn't really zero-sum...just winners and losers

Global market ecosystem and Economic architecture

2009-06-08T09:48:00.000-07:00

Seems like I have been a bit too busy working (not really a good excuse) and keep forgetting (neglecting) to publish, so there will hopefully be a few posts coming more regularly - first one in....

Our world, the global economy, the mess we are in made me think of the wider ecosystem, beyond the reaches of a single enterprise, but the entire global market.

Incidentally, I noticed there was a discussion started on one of the Linkedin groups where I contribute on the topic of "The future of EA in Government. What should stay, What should go?" - now it is more related to management approaches like BPR, ITIL, Agile, etc. (more to come on EA in relation to all the other methods/concepts/approaches/frameworks/etc.), but I thought it is also very relevant if we let our minds wonder for a bit and "investigate" if such economic horrors as seen recently can be avoided (or rather subdued) if “Economic Architecture” was implemented and exploited, similar to what Enterprise Architecture within a "contained" company/enterprise ecosystem?

I'm talking about the higher levels of architecture, not necessarily down to the lowest level of detail (though there might be value in looking at even the smallest things in an ecosystem.

Would we (and more pointing to governments, regulators and businesses) have been able to gain advance insight into what future impact there might be linked to current actions.

If we do implement an approach to economic architecture (or really a global market ecosystem), then there should be an approach similar to what Enterprise Architecture, with a similar value and benefit aspect...though there will be a far more complex application of chaos theory, but in essence we should be able to explore potential risk areas, discover areas requiring change, model solutions where change were required...and in the unfortunate case of something horribly happening, to be able to discover the root cause through “reverse chaos theory”, to ensure that the right corrective (change) measures is put in place and that the change would not just a short lived positive impact to some, but that a sustainable and symbiotic effect.
If applied correctly (though in theory, practice is science fiction at the moment in my view) we should be able to avoid potential future disaster states, instead of the usual desired state...for now.

What is an Enterprise Architect not...

2009-04-27T06:32:00.000-07:00

Following from my previous post (and also derived from a related Linkedin discussion “What is NOT Enterprise Architecture or an Enterprise Architect?”)

This is my view.... an Enterprise Architect (and the function) is not one of the skilled (domain experts, X-type Architects, whatever you want to name them) people/roles/functions that is recruited/interacted with, to contribute (and feed off) the EA function, but EA is the function that sits between all of these to ensure that what each contribute is to be of benefit to all the others.

A lot of views are that an EA set/define the (IT) strategy...
(I see EA as a holistic enterprise function, not just limited to IT (but most of the time working heavily with IT) - already said by most.)
Firstly - What I'm really going for is that EA is not responsible for the strategy (as in setting the strategy - corporate or functional) - what EA (role/function) is responsible for (and should have authority over) is to provide the viable alternatives (and recommendations) for strategic decisions and supporting "evidence" to enable objective decision making by those responsible for strategy (CEO at the highest level and then his/her lieutenants...CFO, CIO/CTO, COO...)
Secondly - EA is also not responsible for executing changes/strategy (IT or non-IT related), but EA is responsible for change/implementation governance in terms of compliance by solution architecture and development/build/etc. to ensure that changes are not fuelling the silo/duplication/conflict effect that EA is responsible to eliminate/reduce.

Short summary from me - what (an) EA is NOT
- The strategic decision maker/s
- The vertical/domain/technology/subject matter expert (this is not saying an EA can't also be one!)
- The programme/project manager
- The skilled resource that will do the development/program/implement the change/strategy

What makes a good Enterprise Architect?

2009-04-02T05:31:00.000-07:00

Following a discussion on Linkedin – “What makes a good Enterprise Architect?” () (started by Mike Rowland from the BBC)

This specific discussion has received the most comments/contributions yet within the Enterprise Architecture network group of Linkedin – most of the contributors stating very similar views (though some with a slightly IT leaning). The views expressed and the “consensus” reached was (in my opinion) perfectly summarised by Roderick Lim Banda (Head of technology Development at MWEB) in his 21 point view. I also think that this is probably the most accurate (once again in my opinion and relevant to my way of thinking/doing EA) guide to an EA’s role definition...the 21 points are:

A good EA is a professional, a visionary leader, knowledge worker - knowing the business and the technology, possesses soft skills to converge ideas, analytical and problem solver, inspires/motivates others, are internal experts, has external network and personal advisors.

A good EA must deal with the complexity of an enterprise and all its parts without losing sight of the whole.

A good EA can produce business value in an agile manner by focusing on the picture of the whole of the enterprise, enough detail at a time and evolving the detail over time.

A good EA is not a designated management position but is an influencial leadership role. To be effective, EAs must therefore influence change in a positive way, hence the art of diplomacy and people skills are the most important qualities for success.

A good EA aligns the two separate disciplines of business architecture and technology architecture, in a systemic way to help an organization achieve its drivers which include the strategic objectives (revenue generation and cost control) and values.

A good EA is able to map the strategic or high level picture and plan to its operational implementation.

A good EA must have the ability to think and work towards making effective decisions and trade-offs for the enterprise and must therefore be able to abstract, think holistically, have a sense of future states, be strategic and tactical.

A good EA possesses a balance of personal qualities to be unbiased or agnostic, pragmatic, enthusiastic, articulate, persistent, enduring, open, altruistic, accountable, honest and trustworthy.

A good EA must excel under difficult circumstances and must therefore be able to cope with the pressures: be a natural leader; be able to work and collaborate with others and in teams; have a high tolerance for ambiguity; rapidly and continuously learn; be an extraordinary communicator; have great work habits and ethics; have courage but not blind conviction; and be passionate about and for the business.

A good EA understands and can support the financial drivers of a profit driven business and the value of intangible assets which include human, organisational, information and intellectual capital of the enterprise.

A good EA has the capability, understanding and skills of related disciplines such as project management, change management, service management, infrastructure and operations.

A good EA has a wide range of experience in and across business and technology domains, including a broad cross-section of the external business environment, internal organization, business processes, operations, enterprise systems and applications, software development and technology solutions.

A good EA must provide views of elements within the enterprise and their inter-dependencies and associations and have the ability to abstract complex views onto a single context or page.

A good EA is able to facilitate, communicate and model views towards different stakeholder perspective, especially towards gaining the support and understanding of executive leadership, management, product owners and implementation teams.

A good EA must have an understanding of what constitutes good architecture as a whole and architectural thinking which includes function, aesthetics and structure.

A good EA must understand the enterprise strategic plan and the top-down and bottom-up changes that affect this, ensuring that these changes are documented and planned.

A good EA must be able to forecast the state of systems which encompass the complex and adaptive nature of an enterprise and its current, changing and future states.

A good EA must not be IT-driven but rather drive technology towards achieving business value.

A good EA does not need to conform to a specific framework.

A good EA as a structure could be a group rather than a single chief architect role within an organization.

Tom Graves added a 22nd point:

A good EA recognises that 'non-functional requirement' doesn't mean that the requirement has no function - it means that the requirement is about quality, which is at least as important as function.

Discovering the Root Cause - Reverse Chaos Theory

2009-03-21T19:16:00.000-07:00

With chaos theory always playing in my mind and at the same time reflecting on the current disaster that is the international economic status, I started wondering about a something that I have used Enterprise Architecture for in the past...the (hopefully proactive) identification of issues or problems (and opportunities) and then the application of “reverse chaos theory” to discover the root cause of the potential issue/problem.

As with the normal function of EA, I also expect to use to facilitate the discovery of the optimal and viable solution within the greater ecosystem.

The basis of chaos theory is that a small change in one place might have significant impacts somewhere seemingly unrelated....so the reverse should be that where there is an impact (issue or problem), there must have been a small change somewhere (possibly seemingly unrelated).

Enterprise Architecture in practice usually has a mostly forward looking application, integrate the diverse and siloed components within the enterprise, defining future optimal structures (and map change plans/roadmap from the current state that link the components of the enterprise together to achieve strategic objects, and to guide/govern change management (unfortunately usually only within the IT context) – I have (and know from a few contacts as well) however seen great value in using Enterprise Architecture to not just look forward for defining a change road map and facilitating change to achieve strategic objectives (or business operational changes), but to proactively help the enterprise to “fix” itself or exploit possible opportunities and to provide decision makers with the evidence to make objective decisions as part of strategic direction.

This however requires a very mature EA function and an organisation (and executive support) that will empower the use of EA to identify potential issues/opportunities and to uncover the root causes (or potential change requirements – this is very closely tied to the Insight component of the model for Value of EA for business change....

Maturity is however a deciding factor, in being able to use the EA function to this extent – demanding that executives to request/require this type of chaos based advice/insight and to use the tools/information at hand to make objective, viable and symbiosis striving decisions.

This line of thought takes me back to the relevance of for a far bigger ecosystem than a single enterprise (and its value chain), but for the entire market (micro and macro-economic) ecosystem (back to the current financial crisis) – if governments, regulators and international authorities (and companies and individuals) evaluate all the issues/problems we face currently and then apply some reverse chaos theory, we they might be able to firstly discover the true, granular components that cause the mess we are in, and secondly to define the solution based on achieving a symbiotic global market ecosystem and determine what is optimal while being viable and achievable....don’t just throw money (that comes from where?) at the problem (as is the case in most businesses as well), but fox what cause everything in the first place and ensure that the same problem will not arise again and that while fixing one problem it is not set in motion to impact something seemingly unrelated.

Enterprise Architecture for Strategy

2009-03-05T09:53:00.000-08:00

A topic I have been exploring recently, actually for some time now, is what Enterprise Architecture’s true function/role and value is to the enterprise (business). The most common understanding and practice of EA is to be able to present the enterprise (mostly IT leaning) in its current/”As-Is” state, model the “To-Be” and then also provide a “roadmap” to achieve the “To-Be” – this to me is a rather reactive “use” of EA, not to mention making it a rather static and “hands-off” function.

More and more I hear (beyond what I have already experienced myself), that Enterprise Architecture (and Enterprise Architects in this) enable and facilitate strategy, and not just IT strategy (that was core of the old form of IT centric EA already), but also to enable corporate/business strategic decisions...probably mostly related to change. Now I totally agree with this, coming from a business background and having seen how valuable EA is and can be (not always realised though) to executives and business managers – so I need no convincing. I actually think this is a good follow-on to my last post Enterprise Architecture Value Model – the emphasis being on BUSINESS change.

There is always change in the business ecosystem (especially at currently with the markets in turmoil – chaos theory in action) - now referring back to my previous post...In my view, EA can serve as a number of tools for the executives, to make the strategic decisions, as well as to identify about what (required and potential changes and opportunities) they should make decision – It is a like a GPS (think about a TomTom) for the enterprise ecosystem...showing maps, routes, traffic reports, police cameras and in some instances even link you online to information and pictures of specific locations – the detail is granular, but relevant...I’m going off track here ;-)...back to my EA value model

Firstly, Insight, EA provides executives (and all other stakeholders) with a view of the current state of operations and solutions within the enterprise (and hopefully also of the value chain and perspective on the market, incl. Customers). EA should be able to discover the immediate/current and potential fault points (the collapse of the financial industry’s format?), as well as to identify opportunities (optimisation, expansion or diversification) – I admit that EA will not be able to provide all the information, but it should/can provide a significant and structured (evidence based) perspective that should alarm or arm the executives to make the critical strategic decisions.

The next components of my EA value model, Guidance and Compliance, although it is more relevant to Program/project management and Solution Architecture, it is still very important from a strategic perspective in the sense that EA needs to guide solutions to understand exactly with that it needs to achieve in terms of strategy, as well as compliance with EA (and the corporate strategy that leads EA) in defining a solution that would not deviate, conflict with other strategies, etc., and be viable within the context of the enterprise’s ongoing operations and the strategic shift – minimising the chaos effect on the enterprise.

Executives will also most surely need to approve a solution before any attempt at implementation can be made – here EA serves a vital role in evaluation of solutions and then also to present the solutions and the evidence to support or facilitate decision making to executives. It is at this point where executives require a significant amount of information to determine if the change in strategy is viable and how it should be approached to ensure that the associated business (or IT change) is the best decision to make.

Enterprise Architects in actual fact become advisors to executives and facilitate strategy through evidence based decisions support – in that sense EA is a strategic role, not just in leading IT, but all of business decisions.

Enterprise Architecture Value Model for Business Change

2009-03-02T03:34:00.000-08:00

Following on from my previous posts on the value of Enterprise Architecture, I was recently requested to do a presentation on how Enterprise Architecture adds value to a business during change.

In my point of view that is the core purpose of Enterprise Architecture – being a tool to help business identify, manage and execute change.

Do note that I don’t just see Enterprise Architecture as a tool required when there is active change in a business, but rather that I see change something that can result from information provided by Enterprise Architecture (as a function or as a tool)

I focused my presentation on a value model that has delivered good results for me in the past (and present). It mostly fit with a change lifecycle, but also applies, as stated above, even when we are not expecting change – the impact/application of chaos theory is very important, but so is the role of EA to provide a structure to function within a dynamic, unpredictable ecosystem.

The model is broken down in 5 stages in change lifecycle or “Values”, though the stages aren’t required to be in sequence or even all used when there isn’t a definite change, though I would recommend following it rigorously to guide a specific change.

Business transformation/changes and programs/projects seem to frequently fail to deliver (and/or exceed budget, deviate from business need, etc.) on the desired business requirements or expected benefits – a lot of this can be attributed to a lack of a tool/function to guide and control change from an objective approach (so not directly involved as a stakeholder or participant in the change/project.)

Enterprise Architecture can, rather should, be the tool to provide the function of objective regulator and facilitator.

The change values are:

Insight

Enterprise Architecture can/should provide the business with deep, stakeholder specific insight into how all components within the enterprise are related to each other, depend on each other and function in a stable or possibly ineffective and/or inefficient state.

Prior to change commencement, if we look at program/project management, this will be a key aspect of the business case, though pre-solution design stage.

Guidance

Following on from providing insight into the state of the enterprise and what is working and what is not working (well or viably), Enterprise Architecture provides business with guidance to what needs or can be done to achieve viability or optimal state (for the current understood desired state of the enterprise).

This aspect of value in the change lifecycle is very closely associated with Solution Architecture and also aid business/requirements analysis.

Compliance

Also directly linked with Solution Architecture is the value in providing a measure of compliance of the defined solution to the holistic Enterprise Architecture, in the sense that it needs to be checked that the proposed solution does not violate or deviate from the greater EA or that it cause conflict with other areas or components of the holistic EA. It also provides a control to test viability of a solution prior to embarking on development of a proposed solution... and I’m not just referring to software applications when using the term “development”, but any change being put to action.

Governance

During the change “build” or development stage it is crucial to ensure that what is being built does not deviate from the approved/viable solution that fits with the holistic Enterprise Architecture. In addition to ill-defined conceptualisation of a requirements and isolated solution design, it is here, during development, where most changes/projects head to failure.

It is something that happens so frequently, that what is being developed (or changed) deviates from the initial approved solution or spiral out of control due to a lack of an objective control source. In that that EA plays an integral role in governing the project progress through staged controls to ensure that the development stays compliant to the holistic EA, the project/change purpose (and requirements) and not break the budget either. This is here

Facilitation

Most changes/projects sigh a breath of relief once development is completed and it complies with all requirements (is within budget and time constraints, etc.) and are ready to take the change “live” – put it into practice and reap the benefits. The post-development change management and solution integration of a change/project needs a lot of hand holding as well. It is easy to just implement a new solution in the areas where it was intended to be used, but this is most often done very isolated, focusing purely on the solution and ignoring all other factors beyond and even not implementing (and integrating) everywhere it is required.

Enterprise Architecture provided the initial view and what can/should change, so it should also function as the tool to show where the implementation will impact, where it should integrate and what change management needs to take place. A comprehensive, holistic EA should be a guiding tool to facilitate the smooth post development change implementation

I would like to reiterate that enterprise Architecture is dynamic, and can/should not just have an As-Is and To-Be states, but current and future/desired states (on which a solution architecture is based). In this dynamic ecosystem, EA can facilitate the change implementation/integration into the business, since it also recognises all the other changes took place during the development of a project/change. There are likely to be factors that not known prior to change conception and during development that will now have to be recognised and address to ensure that implementation/integration is comprehensive/complete and non-disruptive

EA is the tool that ensures that the change/project firstly can deliver the required benefits (purpose and ROI) and secondly to actually achieve the results anticipated.

Without this structure that EA provide we will just be in a chaos environment, where we not drive to symbiosis, but where one single factor could dominate and impose its own deterministic nature on everything else.

To expand slightly on chaos theory – solutions/changes in isolation might look perfect, but we require a structure that can objectively assist in determining if the perfect solution will not impact negatively on something else (and also where else it will impact) – EA can take the uncertainty out of the change.

Some more to come from my Enterprise Architecture Value Model where I will focus on relevance specific to project/change stages and specific “tasks” that EA have.

What is the value of Enterprise Architecture?

2009-01-29T14:15:00.000-08:00

I think to answer that question we need to really look at what is/can Enterprise Architecture really used for.

I'm not talking about ROI (how quick can we recover the cost of having EA), but really what value EA adds to the enterprises that have it. By "having EA", I'm referring to a formal Enterprise Architecture function established (and working) within an enterprise, a function that is the coordinator, integrator and governor of all architectures (domain and business function specific) that make up the whole of enterprise architecture.

I asked the same question to one of my contacts, who responded that from what they can see (as a Project Manager) the only use of Enterprise Architecture is to diagram business process, the data associations and how this relates to applications and technology....as part of a project. It seems like Enterprise Architecture use in a lot of places is just to provide a visual of how a solution will work and then retroactively integrated to an enterprise wide perspective (even in the controlled environment that is IT) - should EA facilitate the solution architecture? Shouldn't it facilitate in discovery of business requirements? Shouldn't it ensure compliance, promote reuse and reduce unnecessary development?

Just a warning, I got the idea (not just recently) that the way I approach/see EA might be a bit more "holistic" and further reaching than others (though there are a few that do agree with me), so if you are not practicing EA the way I do, please don't be offended, but maybe do think/explore the concept of holistic EA.

So to me EA is a comprehensive representation of the entire enterprise with different detail of view depending on stakeholder/use perspective (high level strategic, all the way down layers to operational detail) - it is modelled like a product breakdown structure or decomposition of a process to ensure that the specific users (executive or operational) see what they want/need to see to make the right decisions - in that regard, to me, is Enterprise Architecture as a function's main role to be a decision making facilitator/guide/governor, but it still does not answer what the VALUE of Enterprise (or what ever other name you want to give it) is to the various stakeholders and the enterprise/business as a whole.

To be able to determine (and see) the value of Enterprise Architecture we will only use it, and we will also only be able to realise the benefits and thus the derived value once we start to exploit EA. So the first thing to investigate is what is EA really used for... to understand the enterprise form all perspectives? to use as a tool to explore and discover opportunities for change? to facilitate change?...or to guide change? (there is a difference between these two) to define scope of transformation? to empower project/program contributors and stakeholders? to manage projects? to facilitate managerial decision making? to manage growth? to facilitate strategic decision making? to enable cross-functional/domain integration? to present how IT domains relate to each other? to drive IT strategy? etc.....I'm sure there are lots more uses, especially beyond an IT centric approach

From experience (and some might say what I present here falls outside of EA), I have seen Enterprise Architecture firstly depends (the way I do it again!) on ALL the business functions/areas, verticals and horizontal domains to ensure it is comprehensive and thoroughly integrated, and secondly that ALL the business functions/areas/domains also use Enterprise Architecture.
In this is the first value point of EA - it is a standardised, holistic representation of the enterprise presented relevant to the user's perspective, be it HR, Marketing, IT, or Executive, manager and employee - it is a single source of the current state (think phase space and dimensional relativity) of all components in the enterprise and the relationship between all of them (direct or a number of degrees of separation) - The value is that EA can be the "Single Truth" of the enterprise.

Secondly, if Enterprise Architecture is approached as a dynamic representation of the enterprise (once again my way), basically evolving/growing with the enterprise, it provides the ability to facilitate the design of solutions or change formulation, even shaping of business requirements. I have used EA to perform solution discovery and solution viability testing by defining a future/desired state of the EA (based on "raw" business requirements) and identified the gaps between the desired and current states, as well as to have tested solution options to achieve the desired state thereby identifying the viable solution within the dynamic ecosystem that is reflected by the Enterprise Architecture - the value here was to accurately define change, prevented duplication or unnecessary expenditure and compliance with enterprise stability. So on a change/project basis it is very useful, to define the change, to monitor the change and to facilitate change management and integration.

If it contains the relationships between all the components (incl. things like skills/competencies, process, location, equipment, data item, etc.), we can also gain great value from Enterprise Architecture in defining procurement requirements (we know exactly what is required and the costs relevant to the whole), or to define a job spec for recruitment (we know the capabilities and skills required relevant to the function of a specific role), or to understand the costs allocation per component/function/process in budget setting - the value of Enterprise Architecture to operational management is near endless.

In current times, the financial melt down, with the renewed drive for efficiency, I start to think that business agility and the strategic decisions (to kick-off sudden change) is where Enterprise Architecture will be exploited most. If we know what we do where and what has an impact on the enterprise, then it is far easier to be agile, making rapid changes to accommodate the changes in the market place. Executives gain visibility of where there is excess (dependant on EA being comprehensive and a true representation), where the company/enterprise will suffer if it "optimise" (redundancies, operational cost cutting, etc.) and what is critical for survival...no preferably what can be "modified" to ensure success during an uncertain period. Enterprise Architecture can provide the cosmos, that is used to analyse the chaos.

That, and I'm sure there are more, is the value I see in Enterprise Architecture for the Enterprise - Enterprise Architecture as a function, is a tool that should govern change, facilitate decisions and provide a view of the holistic enterprise.

PS - As an Enterprise Architecture consultant, for me, in the end the value (back at value) of answering "What is the Value of Enterprise Architecture to the enterprise?" is to be able to create a very strong business case for formalised Enterprise Architecture...make the decision makers think, challenge conventional wisdom (subjective approaches?) and gain executive support from all angles.

Where do all the "Architectures" fit into the Enterprise?

2009-01-22T08:10:00.000-08:00

Something that is heavily discussed in some of the Enterprise Architecture groups on Linkedin in is the differences between Business Architecture and Enterprise Architecture.
In my view it is not much more than semantics - we use different terms for the same thing, and in the end it is not the naming convention (though it does help to eliminate confusion) that is important, but that the function is present. In my view (dictionary) Enterprise Architecture means the architecture of the entire enterprise - how all the various components within the enterprise (and its value chain ecosystem) relates to each other. I see Business Architecture, along with IT Architecture, Organisational Architecture, etc. as domain specialist areas that all become part of a holistic and integrated Enterprise Architecture.
This was just the discussions around all the types of architectures - I have a model of how I (my view, not necessarily the view of all Enterprise Architects, business managers or the market) the various "Architectures" relate to each other...I don't think I will be able to cover all the various architectures, but here is a go...

As an Enterprise Architect I get to interact with various architecture functions, including (but not limited to), business architecture, network architecture, process architecture, software architecture, infrastructure architecture, systems architecture, technical architecture, integration architecture, data architecture, operational architecture, organisational architecture, etc. A lot of these functions (roles) would have previously been labelled as "X Engineer"
Now I'm sure there is a fair degree of overlap in function amongst those (if some aren't duplicates, depending on who you speak to).
In the historic, IT centric view of Enterprise Architecture we would have had domains (with the relevant specialists and architects) for Business, Data, Applications and Technology/Infrastructure, but my holistic view of Enterprise Architecture I break out of the IT stronghold and approach things from a business perspective - the reason is that IT is just a business enabler, not the business driver - where there are multiple domains, verticals (business units or departments & functions) and horizontal domains (Data, Process, organisational structure, finance, etc.) are just the mesh that come together/integrate to form the Enterprise Architecture.

I understand that each domain owner (and vertical stakeholder) wants to advance their own importance (or desires), some times to the detriment of the whole, but unfortunately those approaches are usually, can we say "selfish"?
At the same time I also recognise and evangelise the importance of domain/vertical/functional specialists (and architects) - each one as a very critical role to play in making the entire enterprise work (survive, evolve and thrive - I'm a big promoter of the symbiotic ecosystem concept for an enterprise) and in the same breath, each of the various architectures are vitally important to contribute their area of specialisation to the Enterprise Architecture - in a controlled, standardised way and then to also utilise this holistic "tool" to facilitate/ensure that the business survive, evolve and thrive.

So back to how I see all these architectures interlink - firstly as posted before, I see all components in an enterprise as nodes in a gigantic spanning forest graph (each domain or vertical is a tree graph) with relationships between the various trees and nodes (components)...and important to note the value of standardisation and architecture governance when bringing it all together!

So where do they fit in, in my view:
Enterprise Architecture is the over arching, integrated, combination of all the sub architectures (tree graphs) and the EA function is to put all the architecture puzzle pieces together - building a big LEGO model from a lot of different sets.
Business Architecture is the grouped reference for domain areas where a business domain or vertical specialist/architect is required. This architecture is compiled from a lot of smaller architectures (such as organisational architecture, governance architecture, etc.)
IT Architecture (or Enterprise Wide IT Architecture) is the grouped domain for IT related specialities such as applications, networks, servers (infrastructure), technical integration, etc.
Data Architecture is the horizontal, enterprise wide domain that deals with the structure, location, accessibility and matching of all data components
Solution Architecture is not actually part of Enterprise Architecture, but it does feed off EA and then back into EA. Solution Architecture is project/change specific linked to defining the method for taking the enterprise (and the EA) from a current state (As-Is) to a future DESIRED state based on specific business requirements, and very important, it does not necessarily have to be an IT solution! (More to come on the relationship between Enterprise Architecture and Solution Architecture.)
Service Orientated Architecture, in my eyes this is just a philosophy or approach to defining the relationships in any architecture...not technical integration or web services, these are just execution methods linked to a applications in a Service Orientated Architecture.

In some discussions contributors stated that it is impossible for one Enterprise Architect to be able to manage the complexity system, for that I propose domain and vertical experts that feed off and into the holistic reference base. Others were concerned with the level of detail that is required for a holistic and integrated Enterprise Architecture, to this my answer is very similar, provide usability dependant on the level of stakeholder and what the purpose of use of the EA as - this can be rather easily compared to a product breakdown or the method of process decomposition - nearly no detail at the top and increasing in detail as you go down levels.
The Enterprise Architecture function is to put all these separate architecture work sets together so that it makes sense (and is of value) from each stakeholders' own perspective and to provide the guidance (read governance) for change by navigating through the chaos in the cosmos.

If you stand far away enough, you would be able to observe the patterns/order (Cosmos) in the seemingly chaotic. Most people are too directly involved with there vertical/domain (silo's), to be able to see the bigger picture. That's were the enterprise architect and organisational strategist should play a strong part.

If we (me) try to address what the relationships between all the various types of Architecture are, then it leads to another question, what are all these multiple types of Architecture really?

Next up - how is Enterprise Architecture used (exploited) to deliver value to the business.

The dynamic nature of Enterprise Architecture - no static To-Be state!

2009-01-12T06:24:00.000-08:00

A lot of Enterprise Architects and business stakeholders always talk about "As-Is" and "To-Be" models. I understand the use of "As-Is", it is basically a term used to refer to the current state of Enterprise Architecture (or the state, good or bad of the enterprise or a specific business function/area), I just seem to have a bit of a problem with the term "To-Be" - by definition (and application), it demands that a static, predefined "ideal" state (usually centred around a preconceived solution) WILL be realised - my concern is that things change on a daily (sometimes even more frequent) basis in and enterprise ecosystem, so all you can really model are a few (we need some alternatives most of the time) "future desired" Enterprise Architecture states (based on business drivers, like strategy or change requirements).
The next problem with the "As-Is" and "To-Be" approach is that it assumes that it should not be a problem to just create a "roadmap" from the "As-Is" to the "To-Be". My experience leads me to to think that the "solution" that unfortunately usually pre-exist to the "To-Be" (the "To-Be" is usually crafted to incorporate the solution) can not be accurately and comprehensively defined (architected) or in compliance with the Enterprise Architecture (and other changes in progress or required) - can't you only really architect a solution if you know what it is that is required and how it will work/fit in, symbiotically, with everything else?
This is relevant to this topic, but will be explored a bit more later.

Is an enterprise not dynamic? Do things really just comply to an "optimally" structured model and then continue in equilibrium until such time as there is a active decision made to introduce change?

Looking at Enterprise Architecture from the point of view that the enterprise is in reality just another dynamic system,a business ecosystem (my preferred description), then we will need to shelve the ideas of static states (time-dates stamped) "As-Is" (opposed to a "current" (implying that evolution is accounted for up to the point of assessment or Enterprise Architecture consultation) and a static "To-Be" vs. a desired future state (it has a future time/date attached) that is not replacing evolution on hold - the dynamics continue, even if we have future plans!
This is very much lead by factoring in the concept of chaos theory (and dynamical systems), not that there is complete disorder, but that the Enterprise always have an element of uncertainty (associated with change), it exhibit apparent random and unrelated behaviour/impacts, but actually this dynamic system (the enterprise ecosystem) show deterministic behaviour through relationships of the components - thus seeking order and structure (See Chaos vs. Cosmos)

To explain the view of the enterprise as an ecosystem will probably highlight the dynamic nature - there are a multitude of internal and external (value chain and market) components that all have an influence on the enterprise and also an impact on how all these components come together and co-exists in a symbiotic nature (if that is possible). Even though in constant flux (due to external market changes or internal evolution) the ecosystem components needs to be adjusted (introduced, eliminated, modified) and their relationships amended with the aim to achieve a stable as possible state to achieve the enterprise goals (nothing more than surviving and thriving) - Enterprise Architecture serves to record this stable/optimal (or most viable) state, providing the ability to discover change opportunities (issues, risks and improvements) and then to facilitate exploration of a dynamic environment (to drive the enterprise towards the optimal, stable state) to enable change to happen in a controlled manner (reducing the probability of fueling the chaos).

More to come from this topic on Solution Architecture...and "states" of Enterprise Architecture.

The Enterprise Architecture Graph

2009-01-02T04:02:00.001-08:00

I have recently taken the approach to rather than rely on ,so called, Enterprise Architecture tools to facilitate the modeling, integration and management of Enterprise Architecture, to rather use a graph approach to map the extensive and complex relationships between the magnitude of Enterprise Architecture components.
This method also sneakily hid the fact that the classic approach of splitting EA into various domains was not necessary for presenting the architecture (though is still needed to allocate the work to the relevant experts) since all components had equal representation and all are linked via a relationship of some sort.

For some background, this approach stems from work that I have been involved with to create a business solution discovery service called Spanning Forest. Spanning Forest in it self is a type of graph where a spanning forest is a confluence of integrated spanning trees. So each domain is a tree, the entire enterprise is a forest. This also leads to my view on Enterprise Architecture as an ecosystem model (to follow soon).

The Enterprise graph or Architecture graph is rather simple - Each node is a architecture component (with defining attributes) and the relationships between components/nodes are represented by edges in the graph. I like to view the relationships and their relevant impacts/dependencies similar to dimensional relativity - the gravity that nodes exercises on each other. To understand the impact of components on other components or to provide a perspective on the Enterprise Architecture from a specific stakeholder point of view, we take can look at how far components are removed (degrees of separation) and therefor have less of an impact or dependence on another component of the architecture.
Similar to each component node having attributes, the relationship between then also has specific type and attributes, a simple example: role/competency A use data B originating/compiled from data C & D through application E hosted on server F to verify G to fulfil business function H, to deliver on strategy I, etc. In this example A is dependant on E, E is dependant on F, I is dependant on H which in turn is dependant on all the other components - the important bit here however is that I's concern about E or F is nearly non-existent because of the degrees of separation (and the weights for the various relationships), however E is very dependant on F. However, if C change then it will have a big impact on B, similarly if E change A will need to change and probably attributes of B, C, D and F.
It is all just about perspective from a specific component and looking at specific areas of impact (or opportunities for optimisation).

In this graph format we can model all considerations within an enterprise, data, physical locations, business processes, resources, decisions, governance, etc. - each individual component (within the various domains) taking a node and then relate to other nodes as appropriate.

This might not be the approach if the executives and business stakeholders want to see pretty diagrams of processes, but it will provide a holistic model with the ability to accurately view the enterprise from any perspective.

I'm taking this thinking a bit further, bringing in my interest in chaos theory, that in a holistic forest graph with all the relationships correctly defined, it will enable the users to see how a small change to one component might have an impact (big, small, isolated or wide in scope) on any other components in the architecture.
Also consider that minimum spanning forest/tree calculation can also be used for optimisation purposes or the travelling salesman problem can be addressed for specific components.

Noting the above, that the enterprise is a dynamic ecosystem, the Enterprise Architecture will need to have a dynamic state (similar in concept as fluid or thermo dynamics - the system always aim to achieve equilibrium) and can't represent a static future state. It may have a version that is an aspirational future ("To-Be") state that can be serve as a "work-towards-point" when mapping the enterprise from its current state (As-Is).

How can potential job applicants (and the market/employers) know what EA really is?

2008-12-30T04:58:00.000-08:00

......all adverts ask for TOGAF (or Zachman), but then things lose a standard thread...are recruiters (and their diverse use of the term EA) are confusing the market?

Being freshly back in the job market, I started to look a new Enterprise Architecture opportunities. I noticed that a lot of job opportunities refer to EA as different things, and defining the job spec very diverse.
I think this leads on from my earlier discussion about the naming convention of all the "X Architectures" and how Enterprise Architecture compare to Business Architecture or if it was just a naming convention.

Some examples of naming for roles I've looked at:
- Enterprise Solutions Architect
- Enterprise Application Architect
- Enterprise Business Architect
- Business Enterprise Architect
- Business Architect
- Solutions Architect
- Service Orientated Architect
- Solutions/Enterprise Architect
- Enterprise Architect (many times and for all or specific EA domains focused)
- Technical Enterprise Architect
That was just the names, now it gets even worst when within the same role names, different skills and purpose of the roles are specified...

Firstly, 90% of the roles was IT based, with 80% being IT centric (both in purpose and requirements)

I'm wondering, am I the only person (a Business driven Enterprise Architect), that finds this confusing...Are at least 90% of all Enterprise Architects pure IT professionals that migrated from infrastructure configuration, data modelling or application design & development to a more cross domain modeller?
Does SOA just mean integration and web services, so very technical?
Do business, or rather executive level, have any input in recruiting EAs?
Please add any other questions you feel relevant to the topic...

Enterprise Architecture - the components of a business' social network

2008-12-12T08:21:00.000-08:00

Just a quick thought (and will explore a bit more in the next few days) - Enterprise Architecture should represent the whole business and immediate ecosystem, incorporating muliple "business" dimensions and IT domains (Data, application, technology) and integrate all domains/architecture perspectives through a network of relationships.

The perspectives of on the holistic architecture requires the use of graph methods for complex systems. This basically leaves us with a view of the relationships between components, the dependencies & influence and degrees of seperation within the business architecture...the enterprise's social graph and the connections across diverse architectures & domains a spanning forest.

Is there really a difference between Business Architecture and Enterprise Architecture or is it a matter of semantics?

2008-12-12T07:37:00.000-08:00

What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations and approaches? Is there a difference or is it just semantics, causing confusion because of different naming conventions and promotion of individual view?

I have personally used "Business Ecosystem Architecture" and "Symbiotic Architecture" to define, through naming, a difference in my own approach, always with a very heavy emphasis on it being a business (executive) driven and ecompasing the entire organisation and all eliments of it…including the IT centric domains of data, apllications and technology/infrastructure (which is most definitely critical in Enterprise Architecture)

I find it really hard to define/name (communicating to the market) “business Architecture” with the persistent push of classic IT centric EA and then to be able to get IT centric EA practitioners to understand and recognise the universe of business related architecture beyond the IT dimensions (data, applications and technology).
Another big hurdle that “Business Architecture” faces is the preconceived views/naming/understanding of business process modelling, process optimisation and organisational architecture.

Business Architecture, to me, seems like an after thought from a classic EA approach, rather than a holistic/whole-of-enterprise, integrated, optimised model with multiple perspectives indicating the various relationships (interdependencies) of all components (and other architecture domains) in a business.
From experience, it also seems like the general market understanding of “Business Architecture” refers to the non-IT domains of Enterprise Architecture design or the Strategic architecture of a business.

The lines are blurred even further – We know that TOGAF is busy evolving to a more holistic “Whole-of-Enterprise” framework and the application of SOA (Service Orientated Architecture) is also no longer the trapped in the mindset that it serves just for architecture integration, but now promote that everything happening in an enterprise is a “service”

In my normal work I encounter more and more that Enterprise Architecture is moving away from being IT centric/driven (or IT controlled) and recognises, requires & incorporates the multiple aspects and components that were allocated to the “Business” domain.

If legacy IT centric EA view Business Architecture as everything that is not IT and by most others as only the strategic level design, then what is the more appropriate naming convention for “Business Architecture”?

Other terms that I find descriptive, yet distinguishable from Enterprise Architecture, though I agree with Tom that Enterprise Architecture is more the term that we want to use, but it is unfortunately high-jacked by the IT centric origins….Integrated Enterprise Architecture, Symbiotic Integration Architecture, and I like to refer to the “whole enterprise” as the business ecosystem, so Business Ecosystem Architecture…or should Enterprise Architecture just evolve to represent what business architects do today?

Edit: Should I just rather refer to my function as a Business focused Enterprise Architect?

Cynefin - a guide to holistic business architecture

2008-11-26T07:56:00.000-08:00

Cynefin gives a good breakdown of the true nature and content of business architecture in a dynamic system

Thanks to Tom Graves for pointing me to the concept/Framework

Exploiting the market situation - What has changed?

2008-11-26T07:35:00.000-08:00

I'm probably just clueless, but I'm struggling to see what really changed in market...I know that some (a lot of) banks lent people money to buy homes they couldn’t really afford by doing “clever” deals betting on the impossible decline of an over supplied, over priced housing market. The same banks and investment companies recycled potential money between them selves…and strange enough that sure bet of future money didn’t materialise when and the ripple effect was felt throughout an incestuous industry.
So a lot of financial companies got them selves into a big mess (pathetic, yet self rewarding, executive management), a mess that destroyed their market valuations, eliminated the possibility of continuing to recycle fictitious money to fund their operational extravagances and will most probably cost thousands of people their jobs when these leaders of industry attempts to save their backs to the detriment of others.
Probably not so surprising is that some companies just can’t seem to divorce them selves from their horrific pasts but continue to be pirates, just look at how AIG use “bail-out money”, how the investment banks are still excessively rewarding the executives who orchestrated the world market collapse, or the way the Big Three from Detroit comes begging…

It seems like the current mess (and last year’s goldmine) is centred in exploiting the market like a flock of sheep with no ability to analyse or plan. An emotional, hype filled drive in both the up and down sides.
Some examples:
- The rise and fall of oil (peak at $147 now 5 months later not even a 3rd of the speculative high)
- The financial industry riding the wave and channelling funds that never really existed, too much faith in financial organisations, over valued, over paid...now the dizzying decline
- A must buy housing market also was a "sure thing"...prices can never go down right? What if prices ran away from those that had to pay them, what if there was an over supply...like the fictitious money handed out by financial organisations. Too many buildings too few buyers = development companies death

Just over 12 months ago the market was described as fantastic, things was just on the up with no possible decline in sight...oil was rising, but it benefited the oil companies and the traders that reaped profits (to the detriment to the general consumer), financial organisations were paying astronomical premiums for resources that wasn't really adding value (just image...good sales men, poor managers or solution developers)

Now all that can be heard is the horror of horrors that awaits us all...no more credit - should anybody/business have sustained them self on credit? Why would you do that to yourself, live within your means or work hard to improve your situation!
The stock market is nose diving (as is the oil price), companies are going out of business or reducing staff (why not manage those business throughout more efficiently? See comment by Dez on Techcrunch’s article that Technorati is getting rid of resources) did the entire business ecosystem cease to exist, or came to a grinding halt because some financial organisations made a mess or through selling money that they didn't have, circulated money between each other, trading of unrealistic future potential (but a future potential that is only possible in perfect market conditions) or could collect money dished out when things were "only on the up"

It seems like only the overly optimistic evangelists or doomsday profits are given the time of day (and media) to convince the world of their opinion or market approach...very little attention is given to the preachers of logic, sense and a hint of conservatism. Is it that the world, the markets just love to hear about either good or bad, but not about the middle/optimal way? Sure there are the Warren Buffets, who share his wealth of knowledge and sensible approach with the world (though at the same time exploiting the market conditions - which smart person wouldn't?)

Can companies, their executives, managers, shareholders, governments, the average man on the street, not realise that you can't live in excess only to force yourself into deprivation later...history have shown that there will be cycles of prosperity as well as poverty...
The only thing that we can do to continue to grow throughout (and avoid possible decline) is to architect businesses, the market ecosystem and our lives to be efficient yet effective, without waste (resources, money) or excess, but with controls that allow for agility or exploitation of ability.
Architecting the business ecosystem, the confluence of strategy and operations, then implement and follow a sensible approach to operating and conducting business...now if just every body can do that...

The collision of business strategy and business architecture

2008-11-25T15:22:00.000-08:00

A subject that I will get back to - while writing the follow-on to my comments in Efficiency vs. Excess, Exploiting the market situation, I realised that what we might face is a huge gap between actual operations (and market interaction) in an organisation and the business' "strategy".

where will business architecture and strategy either conflict with each other or forced to be integrated?
Should they not be like a body and a brain...the one can't do without the other?

I recently asked a question tho the Business Architecture Community on Linkedin.com - Should business architecture be confined to just one organisation, or should the aim be to incorporate parts of the greater business ecosystem?...this was clearly in an attempt to establish who else considered that strategy is vital to business architecture and that strategy can't be delivered on without the operational business architecture to guide it in operations and market interactions.

I will do a bit of research on where the collision should occur or hopefully avoid the collision and just be symbiotic from outset. I think the results will be very interesting, probably not too surprising if I look back at what I've encountered in most organisations...

Efficency vs Excess

2008-11-24T13:23:00.000-08:00

Something has been running through my mind the last few days...Why does it seem like companies operate in excess (spending, recruiting like there is no tomorrow in good times) while they should actually be aiming to operate efficiently at all times...now that there is a financial scare, every company is cutting back, laying of employees, etc.

Didn't they plan?
Couldn't the executives identify changing market circumstances?
Didn't they think things might change?
why hire excessively if those employees aren't required?..getting rid of them only show that those numbers weren't required from the outset.

I'm thinking there was a black hole in most organisations (and the greater market) where there should have been structure, control and planning - abandoning defining efficient, effective and agile business operations, aimed at achieving goals and delivering on strategy while taking note of market conditions & directions.

To be continued tomorrow..."Exploiting the market situation"

Dysfunctional customer interaction

2008-11-21T14:29:00.000-08:00

It seems to me inevitable what I will write about a customer/market interaction perspective on some occasions.

Recently, actually for the past 18 months, I have experienced the worst a customer interaction approach (call it dysfunctional customer interaction) in dealing with a service provider who I will not name, but can say that it is probably the largest consumer and Business telecommunication provider in the UK.

I'm not going to describe in detail my exact issues, but just highlight the disconnected, dysfunctional nature of the company's customer interaction solutions and processes.

When dealing with a company I, as a customer, expect the company to be able to present me with the relevant information at any interaction point, enable me to manage my account effectively and efficiently through any provided methods and be consistent in information provided and services delivered.

Just a bit of back ground…

The company provide the following interaction & communication methods:

- Call centre (where a customer can get lost and misdirected…or not answered)

- Online account access with facilities for viewing all usage, payment/invoice history and ordering additional services or change services

- Paper invoices and communication

The company use multiple payment methods, but for me the only options are to simply use a direct debit or online payments from my bank account.

I use two main products, a standard telephone line (a requirement for the second service) and broad band internet (their top option)

My first introduction to the dysfunctional customer interaction architecture of this company was that for the two main products (telephone line and broad band), I had to call two different numbers to order (and have separate accounts and receive separate invoices) even though the second is dependent on the first service working …and is linked to the specific service for my location.

I found it very strange that the same sales or customer service representative could not assist me with both requests, but I though it will be integrated once the services are active.

I next use their online facilities to order an additional telephone service for reduced international calling (and received confirmation of activation of my order).

Unbeknownst to me, the company failed to activate the online ordered (and confirmed) service, which I started making use of 7 days after ordering it online.

My first payment (direct debits) was processed as expected, but separate with a different account number for each product – I would have expected to have a single account in the eyes of the service provider, even if I was using two separate (though associated) products of theirs. My online account also only enabled me to view the account information of the telephone line product – information that was very incomplete and out dated…

Then came the revelation…their billing department sent me a letter to advise me that my direct debit amounts will be automatically increased due to excessive use.

Online, my account indicated nothing of such nature and when I contacted their customer service they also was not aware of any irregularities. I finally ended up at the billing department who indicated that I have made excessive international calls and that caused my account to be over acceptable limits…this was rather surprising, since I had an online record that I had international calling services active. I was then advised that the service was never activated by the company – you then seriously have to question online ordering systems and their connection to backend operations!

This issue seemed resolved, though only after hours of calls to billing and customer services.

By this time I have accepted that the company was (and will be unable to see me as one customer) interacting differently with me dependent on the product (broad band interaction Good, telephone interaction bad!)

Five months later I was again surprised when, without notice or authorisation, my direct debits to the company increased significantly (4 times normal monthly value).

I checked online and there was no indication of payments processed or reason for the unauthorised direct debits.

I contacted customer services, who told me that their systems are down.

I called again, this time selecting to speak to "Billing" who told me that they were upgrading systems.

I e-mailed customer service and billing…with no reply

When I finally were able to speak to a representative in customer services (billing systems were still "down due to upgrades"), they had no knowledge of the erroneous direct debits and was unable to assist me. Luckily the next day I was able to speak to billing while their systems were working – the representative indicated that the unauthorised direct debit was attributed to the historical error linked to international calls and a refund was processed…unfortunately their systems went down a number of times there after and reversed any amendments made to my account.

Needless to say that none of this reflected on my online account)…and the same unauthorised direct debits were processed another 4 months.

Another 6 months has passed trying to resolve a number of issues and I have since suspended all services from the company – terminating my customer relationship with the company been the easiest interaction I have had in 18 months!

I may be an isolated case, all other customers can be very satisfied and experience no problems in the way their accounts are managed and seamlessly interact with the company through all methods…but what I've seen I'm not an isolated case.

My question from this whole experience is; how can a business (of any size) afford to not be integrated on all levels of customer interaction?

How can a business operate if it does not have a single view of the customer?

Can it be expected that a customer will not be confused with the conflicting information and treatment?

To me this highlights that there was no business architecture to provide a guide or to implement a holistic customer interaction approach. The company provide multiple paths and access points, a mix of products, but all are disconnected, ultimately leaving the customer with confusion and anxiety, and the company with one less customer.

I call it architected for dysfunction – developing complex individual solutions/processes in isolation, but neglecting to make provision for information share & solution/departments/product owners to be unified or even to integrate reactively.

Dissecting the customer journey

2008-11-21T14:23:00.000-08:00

Can we call the customer journey something more than just a path through a marketing, sales and delivery process?

Should it rather be a holistic model of the collection of, and interrelation and dynamics of all interaction points with the market and individual customers?

I’d prefer to view it as a customer and market interaction architecture operational model.

When defining the interaction model, a key perspective of an organisation’s business architecture, there are a number of questions to be answered and operational practices from the entire spectrum of business functional areas to be investigated, modified and integrated.

I’d like to know:
What do we want to achieve through interacting with the external market and what benefit will it deliver to the organisation?
Where do customers interact with the business and should they always get exactly the same view of the business?

If marketing advertise one thing, but finance send an invoice for a totally different amount (even if it is less than advertised), it still reflect badly - and show that one part of the business doesn't know the rest...even worst if the call centre can't find a person that was already a customer or when a customer is asked over and over to supply the same info.

With all the resources and ata availalbe I find it unbelievable that business still struggle to create a single view of the business' customers

Views on the business

2008-11-17T08:18:00.000-08:00

From my experience, where the focus has mainly been on customer interaction solutions, a problem always presents it self…how can we be sure that accounting, production, IT, etc. are aligned with what we present to the market or that we can be sure the customer will be managed consistently (at a high standard) and provided the same information at any point of interaction with a business…and customers do interact with all divisions, functional areas and departments in one way or another!

Businesses employ various approaches and solutions to address their operational problems/requirements, but it has usually been from a single operational point of view – to optimise some processes, develop operational models for new services, etc. – but it was always to some extent in isolation.
Here is my summary of the formats used for presenting operations in a business:

Basic process flow diagrams or use cases - A single point of view will only be of benefit in a business where operations are isolated and not integrated, think of basic process flows. This represents a single business process or function limited to a single department/application/role, and excludes any factors and ignores the impact beyond the focus area.
Two dimensional process diagrams where both the action and actor is presented is an evolution from basic process diagrams. These swim-lane type process diagrams show what is being done by whom and where each action results in an action by another actor/role. Unfortunately this method is usually unnecessarily complex (due to too many process/actions being represented in one diagram) and are limited to functional or departmentalised focus.
Layered two dimensional processes, a view representation of operational processes that hierarchically presented based on they level of business view – business unit/executive, business process/managerial and activities. This incorporates representation of who is responsible for what and enables “drill down” to see what combined process levels make up higher levels. Process decomposition is usually used to develop lower level processes or to bring the highest and lowest levels together. This approach is also mostly hurdled by its focus on separated business units or operational function.
Multi dimensional perspective is a very complex representation of a business that shows all processes and relationships from various angles, dependant on who is navigating the business architecture. This holistic approach presents all processes (on multiple hierarchical layers), the roles responsible for actions/business processes, business units & departments, operational focuses/functions, applications/tools and attributes (dependencies and descriptive information) that are integrated throughout the business. It is not limited to a single operational focus and takes into consideration all other areas of a business.

While most work is usually done for a single project or operational area, it is also critical to take note that changes introduced (or simple a view developed) does not exist in isolation, and it will impact and influenced by other aspects in a business. A non integrated modelling method may provide a specific business unit, etc. with a solution to their problem/requirements, but it may not unfortunately consider the cost vs. benefit, impacts or demands on other business areas.
Consider though, that unless you have an integrated, holistic view from any perspective of the business, you will get an incomplete and mostly isolated view, with information that could do more damage than provide a solution to the greater business.
A holistic business architecture is a bit of a revolution, by modelling all aspects and perspectives of a business to ensure that all areas, tools, resources know their place in a business and to eliminate possible duplication of processes and tools.

Unfortunately business architecture is seldom holistically implemented due to the complexity in development and the requirement of executive sponsorship.

My case for business architecture, a multi dimensional perspective of the business, is that every one in an organisation, every function/activity/business process and every application is defined in relation to all other entities in a business and provide a detailed guide & model of all operational areas and significantly reduce the probability of issues during changes, since everything in a business can be seen from any angle in how they relate to each other.

Back to my experience – I would like to see that a business can deliver on methods for customer interaction, provide customers with information from any point in an organisation (even if it is not their focus area, or at least direct to the best resource), enable change more effectively & efficiently, limit the impact on other areas of operations – leave the chaos factors to the external market.

Using resources effectively

2008-11-11T05:48:00.000-08:00

Thinking abouyt the huge amount of layoffs over the past few weeks...why did the companies recruite those resources in the first place...was projections so wrong that they couldn't see that they won't need those resources, did they just have too much spare capacity, where the managers in capable of modeling and runnign the business for both fat and lean times...and rather build and structure thye business as it develops and the need presents it self rather than to bulk up "just in case"?

Resource utilisation, productivity efficiency and effective delivery - why do people have time to waste, yet complain about deadlines...seems like far less work is done than a full day...and that work load is nowhere close to utilising a resource

In the various business that I worked with I identified a common trend - people's functions are mostly not strucutured correctly resulting in waste of a valueable resource by demanding them perform not-value-for-money tasks, or allowing them to believe that they are doing "lots" of work when they are actually not being productive. Do we use work to socialise, do managers set the example that work place is for time wasting? The core issue being - are businesses' meetings, operations, etc. architected to force best use of time anddeliver required outcomes/product?

I noticed that 37 signals, the implimented the 4 day work weekand I think they probabily still have spare time to havea few extra coffees or chat about non-workrelated stuff

I belive most businesses can do easily if they just organise themselfs right by applying a bit of business focused enterprise architecture and taking responsibility....

The disconnect

2008-11-10T14:32:00.000-08:00

Something I've noticed in a number of businesses, the seemingly endless drive to grow sales, increase revenue (become kings of the market by being servants to target customers) and business operations' underutilisation and inability to evolve to achieve greater efficiency while stying effective (resistant to change and protective of the way things have always been done)

The problem with this is that the operational efficiency and effectiveness of the business is sacrificed while marketing and sales functions are forging ahead in the market, in the endless game of trying to rule the market.
Now I'm not saying that sales and marketing is not necessary to a business, in fact I feel that they are vital, however, there seem to be a distinct disconnect with achieving increased market share (or the ever enticing performance bonus and other motivating factors) and the operational requirements to deliver if a new deal is closed or a new product (branding, campaign, etc.) are introduced to the market.
It is as if a "sell now, think later" approach is alive in most places.

I will be challenged, that sales never sell a product that they don't have authority to sell (at a given price or within a specific support agreement), nor do marketing promote a product if it has not been carefully formulated and the support functions detailed to ensure that customers can respond.
This is not what I'm thinking of, I'm well aware of end-to-end marketing and sales functions, but rather that the cost of marketing or generating sales is not measured from infancy of activities through to deal delivery.
My concern is that the operational backend is equipped (capable to accommodate increased business, modify existing operational models, etc.) to handle the chaos being fuelled by the market facing functions.
Has the business internally been architected to be agile enough to respond seamlessly to new requirements and deliver (efficiently and effectively) on marketing or new business?

Unfortunately most business units/departments operate "semi-autonomously" within an organisation....we only report on finances after activities (and rely on budgets for a year into the future), IT is expected to modify systems to accommodate any requirements ("...it is IT; it’s their job to ensure solutions are available."), production/service delivery must modify it's smooth running operations around anomalies (though they can also fuel the chaos if new products or operational models evolve from here and needs an outlet to the market - so no one way street) - all these factors of a business needs to be integrated to truly understand how each impacts the others - a holistic business architecture, with perspectives from all stakeholder angles.

Business architecture (and business modelling projects) should not, actually can not, be limited to a single business function (call centre, delivery of a specific product, etc.), but needs to be a detailed integrated representation of the entire organisation - the processes/activities, the product delivery methods/pathways, the systems/tools that support operations, the data required, the technology infrastructure and the roles (not job titles) people take in this complex structure.

Is it worth spending more on generating new business than the net profit will be on that new business? Is it worth closing huge deals if it actually cost more (after factoring all operational costs) to deliver? Can we pay marketing and sales performance incentives when their costs are more than their contribution to profit? From the other side of the battle line - Is it not expected from marketing and sales to drive business demand to ensure utilisation? Should operations (including IT and support services) not be ever evolving to ensure that it is aligned with market possibilities and demands?

All the components (products, departments, functions, roles, etc.) need to have a purpose, subject to the overall strategy. The components must know why something is done, how it impacts other areas...resulting in a net benefit.

The various functions in a business can't take the approach of "if you build it, they will come"! No - it relies on a common goal, striving towards harmony internally to ensure it can sustain or improve a business within the greater dynamic market.

Architected for agility – a thought spawned from…

2008-11-07T08:47:00.000-08:00

defining business architecture in relation to other types of architecture (structural/classic, Enterprise/IT, organisation) when this thought process started running through my head…so just a note of what will follow soon.

Should a business have an agile design approach to business?
I’m not thinking about agility in terms development cycles or ability to relocate offices, but how easily a business can efficiently and effectively accommodate changes in the market, new products and internal limitations & dependencies.
Can the business architecture (Cosmos) survive and thrive within a dynamic system (Chaos)?

To be explored

Chaos vs Cosmos

2008-11-05T16:48:00.000-08:00

Chaos and Cosmos are both words that originated from Ancient Greek, (Cosmos = κόσμος, Chaos = Χάος) and are in fact antithetical, but from the slightly different point of dynamic systems, more specifically the holistic business ecosystem, they may seem to support each other’s application.

Hmmm, how can that be?

First a bit of clarity on the actual meanings of Chaos and Cosmos…

Chaos, misinterpreted and incorrectly used by most, who usually use the word to refer to a state of disorder or rather a mess, such as “Your room is in chaos!” or “It was chaos at work today”. Rather, Chaos actually refers to unpredictability and more specific the relationship between things through various internal and external events, impacts that are deterministic of nature – (more later on Chaos Theory and dynamic systems) the emphasis is on system conditions that seem random but aren't.

Cosmos on the other hand, contrasted with Chaos, refers to order and harmony, definitely the opposite of unpredictability. Cosmos in modern use however mostly refers to space or the universe (and also give rise to the various cosmetology derived terms) – this use of Cosmos as a reference to the universe/space is however vitally important, especially in this context, the universe/space is after all just a gigantic system…though I’m sure it isn’t really in a perfect state of order/harmony, that would require that nothing ever changes!

Now back to Chaos and Cosmos; not so much in how they are conflicting in definition, but rather how the two concepts works together to produce the dynamic business ecosystem.

Can we maybe combine the two concepts, what about something like Chaotic Cosmos…think of a ever evolving state of disorder (Chaos), with actors that influence behaviour and outcomes due to very specific predetermined attributes/constraints/synergies, etc. (deterministic) within a system that is always driven by it’s individual components to achieve order and harmony for itself with in the greater system (the universe/space).
Some views are that chaos is the unseen force/energy that drives the universe; this is probably a very good summary of the combination of the concepts of Chaos and Cosmos.

When looking at just a miniscule system within the universe (though a single system that will again be a contributor to the chaos within the universe) – the dynamic business ecosystem, we face the two concepts very distinctly.
Chaos accurately represents and explains the ever dynamic nature of the business world and the ecosystem that it operates in (both internally and externally to an organisation).
Cosmos again describes organisations’ focus to structure their environment to be in perfect order, operating harmoniously (again both internal and external to an organisation) – focused on having a state where it can happily buzz along generating revenue and delivering optimal profits…if only everything internal and external would just comply to the carefully crafted (sometimes purely theoretical) strategies, processes, tactics, etc. that would ensure the Cosmos of the organisation.

It therefor seems that within the holistic context of the business ecosystem, Chaos and Cosmos are complementary to eachother, while being in competition. Even though the individual elements within the business ecosysytem do strive for order to specifically benefit them, they will never be able to control the entire dynamic system and forgetting that while they impliment actions in aim to achieve their Cosmos, they at that same point fuel the unpredictability in the whole.

Cosmos seems to be limited to a theoretical ideal - even in the universal point of view, since no one contest that an ever expanding, ever evolving universe is truelly in a state of perfect order…but really only in a state of self-organising chaos.

Why Chaos Based?

2008-11-04T02:07:00.000-08:00

Chaosbased.com focus on the application of chaos theory and a number of related (and some seemingly unrelated) concepts, fields of study or business methodologies.

It is rather interesting how the various business methodologies seem to separate from each other, I have a few seemingly disconnected interest, LEGO, Enterprise/Business Architecture, dynamic systems/chaos theory, celestial mechanics, web based business solutions/applications, good food and triathlons – I'm sure some people will make connections between various combinations of the before mentioned, but I can assure you they all are related to some extent and have an influence on each other – the most obvious relation between them all are that they fall in my interest fields and you are most likely to ready about them.

I will try to address a number of issues in the articles that can hopefully be addressed/approached (from my point in any case) through the application or reference to my interests (mentioned above), even if it is just to poke holes in existing thinking, theory and approaches. Most of the time these articles will just flag new ideas/thinking here and are likely to result in yet another article – it is all part of the chaos!

A word of warning, I'm a thinker, a researcher, a model designer, but I'm a horrific writer (hopefully not really that bad, but please comment) – so the content will hopefully be insightful, exploratory, make sense once viewed in entirety (or in relation to other discussions)and maybe even give rise to a new train of thought.

Also hoping to use some of the research and the content published as part of my further studies in Applied Chaos Theory in a Business ecosystem – so it is for my benefit as well.
You will see links to products and some advertising, but also links to related material and references…and I might from time to time refer to my own projects and work-

Who am I?:
Jaco Vermeulen, a Business driven Enterprise Architect, currently consulting and also leading a start-up focusing on a business operational solution discovery & management platform.
Have an MBA from the University of Johannesburg majoring in Technology Management and B2B Marketing, TOGAF certification and PRINCE 2 qualified project manager