Defining Business Architecture

Mike The Architect Blog: Mike Walker Defining Business Architecture

Business Architecture is a burning hot topic these days. I believe it is a key enabler to get us to a more contemporary or new world of Enterprise Architecture (EA). Continuing the shift from an IT centric Enterprise Architecture to a business oriented one. We not only see the evidence by the water cooler but also in the broader community. In the latest Gartner Enterprise Architecture Hype Cycle they classified Business Architecture at nearing the “Peak of Inflated Expectations”. The stated evidenced provided showed:

  • Gartner’s Symposium/ITxpo conference (Orlando 2012) saw more than 2,000 people attend Gartner’s presentation, "Business Architecture: Uniting Business and IT."

  • A Gartner webinar (April 2013) hosted over 430 attendees.

  • Since early 2012, Gartner’s EA research team has taken more than 180 client inquiries from clients pursuing business architecture as part of their overall EA efforts.

This is just Gartner. Other analyst firms such as Forrester has built a flurry of content around Business Architecture as well over the past two years with playbooks, articles and blogs.

I would assert that Business Architecture is the catalyst for the next wave of evolution of Enterprise Architecture. If that’s so, what is it? I will attempt to define it or at least tell you how I’ve been defining it for the past few years.

 

Business Architecture, An Industry Perspective 

Like with most things I go to define, it has often been defined before. Business Architecture is no exception here.  I not only did this with how I’ve defined Business Architecture before but also wanted to pull from an updated definitions from around the industry.

While there are quite a few Business Architecture definitions out there, I pulled only the ones that were coming from either influential or credible sources. These few definitions from analyst firms and standards bodies should give you some contrast into what some of these leading organizations define Business Architecture:

  • Gartner : "enterprise business architecture" (often called "business architecture") as the EA activities that create deliverables to guide people, process and organizational change in response to disruptive forces and toward desired business outcomes.
  • Forrester:  An organized and repeatable approach to describe and analyze an organization’s business and operating models to support a wide variety of organizational change purposes, from cost reduction and restructuring to process change and transformation.
  • TOGAF 9.1:  A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
  • OMG Business Architecture Working Group: a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.

 

Each one of these definitions have very good qualities and resonate on their own. However, the challenge I have personally is that I don’t think they are inclusive enough for what I see and teach in the market place. The reason I say this is for the following reasons:

  1. Don’t see these definitions being fully representative of what I see from the hundreds of customers I have visited in the past 5 years
  2. None are comprehensive nor clear enough the I could explain to an executive or a novice
  3. Some of these definitions predicate that business architecture is a stand alone discipline which I fundamentally disagree with.
  4. Lastly, the definitions are just all over the map. Some describe it as the output, some as the process while others dictate a certain outcome

A Definition for Business Architecture

For me, I have a very specific Business Architecture frame of reference for what I believe business architecture is based on. This is through my experience working with customers that have leading Business Architecture practices, my personal experience building out Enterprise Architecture practices  and the workshops in which I teach EA’s about Business Architecture.

In my post, “Australian And New Zealand Architects Surveyed On Business Architecture”, I talk about how Business Architecture boils down to rationalizing the "Why" part of the question into a set of usable things that we can execute on. For me it’s that simple.

The definition I have been using for some time now with customers is the following:

A formal method and a set of descriptions that distill the business environment and the needs of a business into set of models representing business information, concepts, value and risk that are expressed through an architectural view of a business.

 

With this definition I wanted to be inclusive of all aspects of business architecture. I found most descriptions or definitions are too narrow or prescribe a particular outcome. I believe that business architecture is a means to an end not the entire solution all unto itself.  Business Architecture is a critical part of Enterprise Architecture, ensuring all of the EA oriented in a way to maximize value.

As you may of noticed, I have highlighted certain words. For the rest of this post I will go through the highlighted words in the definition in an attempt to explain each on independently to show how they relate and describe Business Architecture.

So lets start decomposing the the definition.

 

#1. Operates within Enterprise Architecture [Implied]

While not stated in the actual definition, it is implied that business architecture is a domain within Enterprise Architecture.  

Mike The Architect Blog: Mike Walker Defining Business Architecture. Business Architecture operates within Enterprise Architecture

Business Architecture on it’s own only provides a small subset of a complete solution. For example, only understanding a business model doesn’t get your stakeholders any closer to defining a solution to a problem or opportunity. It’s when you bring in the macro level EA methods combined with the other domains of architecture where you really see the power behind business architecture.

From an industry perspective, there is a tendency to try to make business architecture an independent framework.

This approach is very dangerous.

Th
ere are many motivations for this, some I believe are the right motivations but the implementation in my honest opinion are very wrong. I think so of this stems from a misunderstanding of the intent of Enterprise Architecture. The challenge comes in when we mix the current state environment in which some organization implement EA or lack there of and the definition of EA from the EA standards community.

As an example, I was digging through my personal archives of content and found a TOGAF 7.0 overview deck from the Open Group. I was surprise to see, even then a business outcome focus from the EA community. Note however, there was not a whole lot of guidance around this until 9.0 but the intent and direction was clearly stated from the very early days of the TOGAF standard.

Mike The Architect Blog: Mike Walker Defining Business Architecture. TOGAF 7 Illistration of Business Focus

This topic can go on for awhile and most certainly warrants more decomposition of the current state, so keep us on point here I will be writing more about this in another post.

 

#2. A Formal Method

With most definitions that I harvested over the years, I see business architecture as a thing you produce. If we examine both the Gartner and Forrester definitions, they  call it out as a very specific set of approaches to Business Architecture.

IBM also states it really well with this explanation in an IBM whitepaper entitled, “Actionable Business Architecture: An IBM Approach”:

[Business Architecture] Methods are techniques that weave through the various contexts using proven methods… [Business Architecture] Methods should also describe the how-to of execution while enabling further integration into an Enterprise Architecture (EA) context method.

I believe that Business Architecture isn’t a deliverable but rather a discipline within Enterprise Architecture that has a set of methods, roles and artifacts that serve to solve a very specific part of a problem. Arguably the most important aspect, the context into why we are doing an activity along with ensuring what is delivered ultimately provides the most benefit back to the company.

The challenge I have with some interpretations of Business Architecture is that it is either implied or explicitly defined that a specific artifact is the results of Business Architecture. The OMG definition is a good example of this with stating, ”blueprint of the enterprise”.

The problem with this is that this is really meaningless with out some purpose. To what end does this blueprint serve. You could also replace that with business capability model and have the same questions. What I sometimes find and advise against to my clients, EA’s should not pivot there work off a specific artifact or deliverable. Focus on the outcome you wish to achieve and work through a proven method to generate a consistent result solving that problem.

Without a method you will find yourself generating artifacts for artifact sake, while sometimes we get lucky, we know that hasn’t yielded effective results. 

 

#3 Distilling a Business

Mike The Architect Blog: Mike Walker Defining Business Architecture. Models of Business ArchitectureAs mentioned above, a big component of business architecture is to distill and rationalize a business. What does this mean? Simply put, let’s understand what the business wants by putting their needs and wants into a set of constructs that us as architects can understand and facilitate the decision making process.

While this is a simple concept, it is very important tone setting statement. Business Architecture does not create business strategy but rather it serves to understand it. There is a very clear divide in the industry here. I believe it is the case here based on the evidence I see in the industry along with other thought leaders in this space. Here is why I don’t think Business Architecture 

Is there a role for Business Architecture in creation of strategy? Yes. But it should be leveraged as a tool to enrich the basis for the corporate or business unit strategy not as the defining method.

So lets take a look at what two primary aspects are distilled.

#3a Business Environment

This aspect is one in which that is easily overlooked because it can be seem that it so far away from solving the actual problem. Sometimes it is but more times than not this aspect is vital to making the right decisions. 

Here we are looking at the surrounding business environment of the problem that is to be solved with Business Architecture. Meaning everything around the company which can include an inwards view but mostly an outwardly view.

This can includes but not limited to the analysis of:

  • Regulatory Environment
  • Competitive Landscape
  • Corporation Health, Financials, Market Standing
  • Economic Condition (Local, Regional, Country, etc.)
  • Geopolitical Conditions
  • Pandemic Considerations
  • Likelihood of Natural Disaster

The list of areas to include in understanding a business environment are vital to how we as Enterprise Architects build our solutions. You maybe asking why these are so important. Or maybe you are wounding why are things like pandemic or natural disaster included here. Let me give you an example.

Lets rewind to Katrina in 2005 and look at the challenges from the banking industry. When this horrible disaster hit, banking locations were closed for weeks. If you were a small bank you might have your entire business and IT environments in the impacted area. Understanding these conditions are important so that you can plan accordingly. Meaning you architect for these considerations.

This was one small example, but for global organizations operating in many different countries with different considerations we can understand those to provide an optimal solution for our businesses.

 

#3b Needs of a Business

This one is fairly broad but meant to be. Often times you see Business Architecture defined as taking in strategy  and doing something with it. While I think this is certainly one use case but I don’t think it is the only one.

The reason for simply saying “needs of the business” is to be purposefully that broad. It shouldn’t matter what comes into the Enterprise Architecture process, all of it should be understood from a business perspective.  Even if that thing is a great new technology trend like wearable technologies. We would still want to understand the business implications and opportunities it presents to a business regardless if it comes through the technology architecture domain.

In this definition “needs of the business” is a way to define what ever the business wants. We don’t want to be prescriptive here as it would lead us down one specific path. These needs are usually through one or more of the following:

  • Enabling the business through:
    • Strategic planning
    • Major business transformation activities
    • M&A support
    • Value management
  • Creating architectures that support initiatives or programs
  • Managing the Enterprise Portfolio
  • Change Management

 

#4 Business Information

Mike The Architect Blog: Mike Walker Defining Business Architecture. Hierarchy of Wisdom Relationships This is the first type of output defined here in the Business Architecture definition is business information.

Lets take a small step back and understand what we mean by information. I don’t mean data.  Data is context-less raw facts about things, while information is much broader and has an important element, meaning. You can see a visual this represented in the visual from Barry Ritholtz’s blog post entitled, “Intelligence Hierarchy: Data, Information, Knowledge, Wisdom”. Keep in mind this post wasn’t from the vantage point of an EA but nevertheless he does a good job articulating the difference between data and information. 

A growing trend in today’s economy is that goods and services are starting to serve as an end to the real currency, which is information and/or intellectual property. From a business architecture perspective information is a key element of understanding where the business was and wants to be. 

Below is an example of some of the ways information provides a meaningful Business Architecture:

  • Identifies the business information entities required to enable a business architecture
  • References an enterprise data model for a clear definition of what business terms mean such as customer or product.
  • Classifies information into segments for better understanding and usage within a solution
  • Provides facts on market place.
  • Prescribes a large part of a business process by defining the information in which it is facilitation the flow of.

 

#5 Business concepts

The term used here is another broad but purposely broad term. It is meant to encompass all the business concepts we want to articulate for our business architecture. There are quite a few of them so the rational for using business concepts rather than naming 20 different business “things” was to not be prescriptive. Also I am sure there would be some left as well.

So here we want to identify a category of business oriented concepts that would involve modeling all the different aspects of a business. This could include but limited to the following:

  • Customers
  • Products
  • Entitlements
  • Goods and Services
  • Competition
  • Drivers, forces or motivations
  • External relationships
  • Capabilities and processes

By examining these aspects along with their relationships we can understand the needs of a business better along with creating a model for realizing value.

 

#6 Business Value

Enterprise Architecture is a methodology that is business value driven. Business Architecture as a key domain within it inherits this position as well. An outcome of this and any architectural process should be defined and a model for maximizing value for a business. Business Architecture is square in the middle of taking a business case that was (or wasn’t) defined and ensuring it can be quantified and qualified.

In Business Architecture we identify, define and quantify value that will serve as the basis for all other architectural work.

Through leveraging value and benefits management techniques we can properly. This is much like a traditional financial analysis that would include the valuation of existing investments and the forecasting of new opportunities. Through this process it’s important to use models that either resonate with your business or are common in the financial industry.

Examples of value models include:

  • Value Chain
  • Benefit Dependency Network
  • Value System
  • Value Network

Those models will help you understand a broader value picture. Additional models that can be used as inputs into these are:

  • Risk Adjusted Value (RAV)
  • Net Present Value (NPV)
  • Total Cost of Ownership (TCO)
  • Return on Investment (ROI)
  • Cost Benefit Analysis (CBA)

Business Architecture not only models value but also determines how value can be maximized. This is one of the benefits that Enterprise Architecture can deliver. It can identify new opportunities not seen before by business stakeholders.

 

#7 Business Risk

We just looked at value and understanding benefits but there was one aspect not covered within it, risk. Understanding value has two facets, benefit and risk. Understanding risk within Business Architecture  allows us to do the following:

  • Take a business centric approach to understanding threats
  • Identify potential harmful risks to the company
  • Classify business information in an informed way
  • Qualify or disqualify potential solutions
  • Understand risk the risk tolerance of the corporation or a specific business unit
  • Examine readiness factors such as organizational and technical readiness.

Through the usage of risk management techniques within Business Architecture we will be able to identify, assess, and prioritize business risk to ensure that risk is well understood and managed throughout the architecting process.

Through this quantification we should use standard risk methods such as:

  • Risk assessments using a composite risk index
  • Risk options matrix
  • Risk mitigation plan

 

 

#8 An architectural view of the business

This aspect of the definition addresses another key debate in the industry. It is perhaps the most important mental framing concepts of the definition. I often hear Business Architecture described in one of two ways.

  1. Business Architecture creates business strategy
  2. Business Architecture is a method in which Enterprise Architects can rationalize the needs of a business so that it can be executed upon.

Based on the rest of this post you can see where we are going here. In my definition of Business Architecture we are looking at a business need through the lens of an architect. This means that we create models that we can use through the architecting process. They are not:

  • In 100% business only language
  • entirely describing business planning or strategy activities as performed by a business planner or corporate strategy.

With this said, Business Architecture should be presentable to business unit leaders (as with most architecture artifacts) which the artifacts and models created should lend from the business world primarily but not at the expense of architecting.

 

Conclusion

I hope this definition of Business Architecture has been helpful or enlightening. However, given the wide variety of definitions in the industry I am afraid not everyone will agree. I hope to hear from you on whether this definition
of Business Architecture resonates or not. 

Advertisements

Come Join Me and Influence Enterprise Architecture Capabilities and Business Architecture

At the Open Group Conference in London I will be leading two very impactful work streams for the practice of Enterprise Architecture. The first is an Enterprise Architecture Capability Model. This model takes the concept of a capability and applies it to the outcomes you want to achieve from Enterprise Architecture. If done right, this will be a huge productivity gain for enterprise architects.

The second is another highly highly impactful area of Enterprise Architecture, Business Architecture. If your an Open Group member and have a passion for advancing Business Architecture please join the group of high caliber architects to advance this area of EA.

Below you find a more through overview and scheduling details for just the EA Capability session. To attend the Business Architecture work stream you must be a TOG member. If you want to talk to me personally at the conference or otherwise please leave a note in the comments.

Details for the Enterprise Architecture Capability Sessions

Attendees of the Open Group London conference are welcome to join the Open Group’s EA Best Practice Development Workshop on Wednesday Oct 23 9:30-12:30. In the workshop, we will explore best practice and benchmarking based assessment of enterprise architecture management and process maturity. Our purpose is to enable organizations to identify and execute improvements that deliver real business value.You might of seen some of my EA Capability work before, if not below are some links that might be helpful. Within the Open Group the view on the work will take a similar approach.

During the workshop an EA Capability Model, Assessment and Best Practice framework will be presented. As a participant you are expected to ask questions, make comments and influence the development of the framework. Your experience, expectations and requirements will through a series of round table discussion sessions.

In developing this best practice and benchmarking it is very important that the Architecture Forum understand the views of Open Group customer organizations that do Enterprise Architecture in-house, as well as experts in the field.

This workshop has very limited space and requires a reservation. To attend you must be registered at the Open Group conference and have a workshop reservation. To obtain a reservation please contact Raina Wissing (r.wissing@opengroup.org)

 

Don’t Get Caught up in the Architecture Modeling Debate

Mike The Architect Blog: Don’t Get Caught up in the Architecture Modeling Debate - Mike Walker

Communicating your ideas and architecture work effectively can be really tough. When we do we using create compelling visuals or models to communicate the complexities of our work. When I talk to architects I find there are many out there that really struggle with getting their messages across to their customers. They also feel that sometimes their communication is just out of their control or the audience just doesn’t get it. Meaning, they should get it, what were they thinking, right?

But is it really there fault? Maybe, maybe not. 

The genesis of this post came from a series of recent conversations. I wasn’t sure if I wanted to create this post or not given the topic but in the past two weeks I have wither run into scenarios or have been asked specifically about this topic. The questions were all different but all led to the same basic theme. These questions included:

  1. General modeling questions. What architecture modeling language should we use?
  2. Specific notions. Should we be using ArchiMate notations instead of BPMN and UML?
  3. Assertions about tools. PowerPoint isn’t for architects, Visio or [EA Tool Name Here] is. 

For as long as I have been in IT I have seen this. The same debates but with different names continue on. For those that have either worked for me or know me I have had the same answer for some time now. But lets wait on that door a moment…

It’s a funny adaption to a very real situation. I often find my self in a modern day Capulet vs. Montague battle between which is the better way to describe the things we architect.

“What’s in a model? That which we call a Business Capability Model,
By any other name would it be as effective to describe our business”
                                  
– adapted from Act II, Scene II of Romeo and Juliet

There are a couple aspects to this scenario. The first is the tooling. I usually see three camps here. The EA tool folks that use it for modeling, the Visio folks and the PowerPoint folks. Then comes the real holy war, the actual notation. Some say it’s UML, some believe it’s ArchiMate while others just stick to their homegrown methods.

While sometimes interesting to watch, it can be frustrating to watch the debate. What it ultimately boils down to is, while we are having debates about which tool and notation the following isn’t getting done:

  • Work isn’t getting done.
  • Decisions are not focused on the right things.
  • Communication has broken down.

I think we lost our perspective on why we create these rich visuals, models or diagrams. These serve two primary purposes in my mind:

  1. Communication tool to gain buy-in or consensus to support the decision making process.
  2. Facilitate the architecting thought process.

You might say, well Mike, you forgot about all the rich things you can do in the modeling notions that can link aspects of your architecture together in a very qualitative way. I agree these are important and sometimes be game changing if you are at a level of maturity to support it. However, if the two primary aspects are not covered, what you modeled is shelf-ware. If your stakeholders who are paying for your effort can’t buy-into your architecture just for the simple fact that they can’t get their heads wrapped around our world of architecture, we have failed as architects.

A model being used as a communication tool, is the most important aspect in my opinion. This isn’t just my opinion but that of the architectural standard for describing architecture, ISO/IEC/IEEE 42010:2011 or formally known as IEEE 1471. In this standard, there is a core problem we are solving (i.e., Mission) with a set of stakeholders that have concerns that need to be addressed. Those concerns are addressed through the architecture models (i.e., view points, views and models).

The problem we get into is we want our models to be perfect. This may mean a high order of fidelity in the models, highly detailed or have a high level of precision. The challenge here isn’t perfection but that of communication to our stakeholders that have either sponsored (i.e., paid) for our efforts and/or need to buy-off on the architecture before it sees the light of day. Like the quote about truth, “the right model is in the eye of the beholder” or the Don Box quote, “All models are wrong but some are useful”.

So if we agree with the assertion that the critical component of a model is used as a communication method to stakeholders of all different varieties, then let’s consider the following breakdown to not choose the one model to rule them all, but rather a set of fit-for-purpose models that apply to the appropriate audience along with the right situation.

I break the models we create as architects up into two categories and add an additional one as the supplemental repository for ad-hoc models that fit only special circumstances.

  1. Consumers of Architecture Work. These models are specifically designed for the consumers or stakeholders of architecture work. These individuals are different in that they usually not EA’s with that specific discipline knowledge but that of specific business unit areas.
  2. Architecture Professionals. These models are specifically designed for the architecture professionals. They have the EA skills necessary to understand the chosen set of modeling tools and notations for the purpose of communicating, making decisions and facilitating the architecting process.
  3. Supplementary Models. This class of models is used a bit differently than the other two. These are used in an ad-hoc nature to supplement the first and second. While these models are usually more oriented to the architecture professionals they can also include consumer oriented views as well.

Below is a visual that describes this as well:

Mike The Architect Blog: Choosing the Enterprise Architecture Model - Mike Walker

 

The reason we want to break these up this way is simple, one set of models you use to communicate directly with your stakeholders or as I labeled them consumers of the models to be a bit more generic. These people who view these models do not have the architectural skills you do nor do they understand the complexities that go into our job. More times than not, it can be determinate to try to educate on the architectural detail as they don’t have the understanding or the experience to fully understand why the decisions were made.

On the other side you have models for architecture professionals. These people are very knowledgeable in the architecture space. More times than not, they are looking for detailed models with a high degree of rigor to understand the impacts the architecture may pose. I have also referred to these people as the “Builder Guild”.

Why call them that? It’s simple really. Just like in other well established profession you will find that the practitioners very different when among their own professionals versus in front of their customers. A great example of this is with home builders. I have built several homes and have had the same experience. I never got a blueprint. I only received a layout with dimensions and maybe a 3D video. Outside that I wasn’t provided anything else. The builder gave me as much as I needed to make a purchase decision with that model and others.

 

When we reflect back to the problem at hand I would strongly suggest we treat the way we communicate along with the visuals we provide just like how many other very mature professions treat it. If we do that, I think we will be much more effective in our success with our customers.

Mapping back to the structure defined you will see some interesting responses to the questions that were asked.

#1 What architecture modeling language should we use?

It just depends on who you are talking to. A consumer vs. an architecture professional. For an architect perhaps you want to use an industry standard notation like ArchiMate. However if you are talking to one or more people from across your organization like a business unit executive perhaps you want to throw out all those complexities and go straight to either existing visuals that have worked well or build less structured visuals with styles that he/she is accustom to.  

#2 Should we be using ArchiMate notations instead of BPMN and UML?

If we build on the first question and assume this question is geared for an architecture or IT audience then it would be the right question to ask. Keep in mind all of these notations are tools in your virtual EA toolbox. Each one of these notations has a role and caters to a specific audience. Each one of these has a discrete audience and purpose. ArchiMate for architecture, UML geared for software development and BMPN built from UML to describe business process more effectively. My advise, don’t try to use one for everything, make sure what you build is fit for the task at hand.

#3 PowerPoint isn’t for architects, Visio or [EA Tool Name Here] is. 

I heard this statement more than a few times, with some more negative in tone. My belief here is all three classes of tools are appropriate for the right situation.  The tool that seems to get picked on the most is PowerPoint. In my own experiences or have seen / witnessed, there have been very clear successes with using a tool like PowerPoint. Remember, it’s not the tool or the notation, it’s the circumstances and the audience in which you are addressing. 

 

So the final words of wisdom, don’t get caught up in the architecture modeling debate. It’s just a model, get over it. Reverse engineer from what the expectations are from your stakeholders.

It’s Been A Busy Summer

Mike The Architect Blog- Mike Walker - It's been a busy summer

Wow, it’s been 2 months since my last post. I can’t believe it’s been that long. Things have surely heated up this summer . Outside of spending some quality R&R with the family, I have been extremely busy in three areas:

  • Lots of speaking at both EA and technology conferences
  • Providing advisory services to executives and EA alike
  • Taking a stronger leadership role creating EA Standards

 

As many of you know, I frequent EA conferences whenever I can make it happen. This summer being no exception.  Over the past few months, I’ve talked to many of you and you have commented favorably on the content on my blog. I wanted to send a very public thank you. I am usually writing from direct experience or providing emerging thoughts based on those and it’s great to hear that resonates. Given that, over the next few weeks I will post up more content based on the questions and feedback from my presentations. This will also come with some extended materials that will provide more context into my thinking around those topics. As the year is coming to a close, the last two events major event of the year I will be going to for sure will be:

 

One of the best parts of my job is getting out of my office and into the thick of it with practicing EA’s. I’ve had an absolute blast talking with executives and EA’s about their challenges and how to enrich aspects that are working really well. Not only do I get to share my experiences but I am also learning a ton as well.

 

Outside of collaborating with practitioners and speaking at conferences I’ve been busy with standards work. I have, “put my money where my mouth is” . A few months ago I posted the “Call to Action” for EA’s who want to make the profession better to contribute to the standard. So that is exactly what I am doing. I am taking my real world experiences and bringing it back into the standard. 

As of the last member meeting at the Open Group conference I am directly leading or providing substantial focus and leadership in three areas:

  1. The Next Version of TOGAF
  2. Business Architecture Work Stream
  3. Enterprise Architecture Capabilities

If any of you out there has an interest in participating in these activities, please let me know via my Twitter handle @MikeJWalker. This is especially true if you are an internally facing company practicing EA. One of the key objectives of building the next wave of the standard is to ensure applicability to all of you and base on proven practices.

Sorry for the lack of “meaty” EA goodness in this post, but several of you out there have asked where I had gone and thought it would be good to give all of you an update on what I’ve been up to outside of blogging.

 

I can’t say it enough, a big thank you to all of you that have stuck with me all these years reading my ramblings on blog(s), twitter comments and listening to my presentations. I can’t thank you enough.