Aggregated enterprise architecture wisdom
Starting a business architecture practice is definitely hard work, but building a sustainable practice is even harder. The data I am seeing is that 60% of business architecture initiatives are failing. The biggest challenge in moving from startup to sustainable practice is that the enablers for starting and propelling a startup forward are not the […]
As announced last year, I will be presenting at the OMG Business Ecology Initiative’s inaugural “Optimization for Innovation” Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit.  …
As announced last year, I will be presenting at the OMG Business Ecology Initiative’s inaugural “Optimization for Innovation” Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit.  …
As announced last year, I will be presenting at the OMG Business Ecology Initiative’s inaugural “Optimization for Innovation” Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit.  …
As announced last year, I will be presenting at the OMG Business Ecology Initiative’s inaugural “Optimization for Innovation” Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit.  …
Design Thinking is more than thinking differently; it is working with, and for, people from the very beginning in order to create better outcomes. The key is engaging your executive sponsor and demonstrating enough value […]
The post How to Sell the Value of Design Thinking appeared first on Enterprise Architects.
Implementing an effective enterprise architecture program is about more than just selecting a tool to aggregate and visualize data. As an EA solutions provider, we talk to a lot of organizations in the early stages of implementation, which gives us a unique, clean-slate perspective on the selection process. Frankly, the most obvious misstep that we see is an emphasis on the functionality of the tool versus what it can ultimately accomplish toward real business success.
Often, when we get into the room with an organization in the evaluation phase, they tell us about how the EA tool(s) they have used in the past delivered little value and poor insights. They want to jump right into the functionality our tools provide as if the functions themselves are the missing puzzle piece. Yes, it’s important to access the metamodel and to be able to load and manage the data repository. But it’s also integral to understand data reports and analytics as well as ensure security and scalability. The tools can almost always collect the data; it’s what you do with the data that creates value. That value can only be measured against goals, so that is typically the first bridge to cross.
Know What You Want To Accomplish
Start by identifying quantifiable business goals that will signify a successful implementation. These goals help define what success looks likes and keep everyone on the same page regarding the desired end result.
What A Quantifiable Business Goal Is NOT:
What A Quantifiable Business Goal IS:
Arm Yourself to Achieve Value
The success or failure of tool implementation most often has little to do with the tool itself. It’s the organizational and planning aspects – where human error can occur – that are most critical. Every organization has unique variables that factor into their implementation, but we have seen a higher probability of successful selection of platforms and tools when the following are in place:
That last point is especially important, because if you can’t work out the ROI, you are in danger of doing the wrong thing and selecting the wrong tool.
Don’t let the list intimidate you; let it guide you. Following it helps you drive business transformation with your stakeholders. The key is to recognize the challenges and find practical ways to overcome them, which is where experience helps.
Learn From Those Who Have Been There Before
Almost as important as the tools themselves are the advisors behind them. Consultants draw from best practices identified through hundreds of engagements to help clients navigate the complex terrain of establishing a successful EA practice, so being comfortable with and confident in them is part of picking the right vendor package. Many of the best consultants were previously EA customers, so they have faced the same challenges and have the foresight to help companies plan for how they can work with data and effectively bridge the gap from tool functionality to underlying business value. It’s important to keep this in mind. When it comes down to it you are not just selecting a tool – you are also selecting the people that stand behind it.
So remember before you select your tool, you need a thought out, formal EA strategy and the reliable experts to help you accomplish it. Remember: The bells and whistles of your EA tools do you no good if they don’t have an established, demonstrable purpose and you lack the trusted advisors that can help you achieve your goals.
Check out whitepaper, The Power of Enterprise Intelligence, to learn more about how our solutions help decision-makers take a step back to see the big picture to understand exactly where they should be investing in their business.
Once upon a time long, long ago, in the Dark Ages, people would identify the need to undertake a significant activity within their business they would call this thing a project
The project was in essence a rallying call for resource and money and executive sponsorship.
Once kicked off the project would make sure it postponed the delivery of value into the organisation (or for its customers) until the last possible moment, or sometimes never.
Then there was a period of enlightenment, people realised they could structure projects in a different way, to deliver value early and often.To test assumptions about projects early so that if they fail they fail early and at a lower cost.
The Enlightenment, what a wonderful time. Wow! lucky we wised up, what were we thinking about in the dark ages!?
Er…except for some the Dark Ages isn’t ancient history. In some organisations the unenlightened approach to change still exists.
Why is that? Why is there often inertia to enlightenment within the business function that should most readily accept change?
Have you experienced an organisation that is still in the Dark Ages? Get in touch on Twitter
At our recent customer conference we took a moment to share the common characteristics we see in our most successful customers. Since this was so well received by the conference attendees we thought it would be a good idea to share with a wider audience.
In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture. In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started. He felt that the canvas is useful for creating a clear picture of the business impacts on a program. There are problems with this method, which I’d like to share in this post.
Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.”
A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs.
For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.
The practice presented by this talk is troubling to me. As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out. By doing so, he or she would understand “the” business model that impacts the program.
During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models? The presenter said, in effect, “we only create one canvas.” My jaw dropped.
A screwdriver makes a lousy hammer but it can sometimes work. The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.
The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program. First off, programs are transitory, while business models are not. The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business. Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time. It is completely inappropriate for capturing two different models on a single canvas. Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.
I have no problem with using business models (although my canvas is different from Osterwalder’s). That said, I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas. The session speaker specifically rejected this idea. I don’t think he is a bad person. I think he has been hammering nails with a screwdriver. (He was young).
Here’s where he made his mistake:
In the oversimplified value stream model above, Contoso airlines has three business models. The business owners for these three businesses are on the left: Bradley, Janet, and Franklin. Each are primarily concerned with their own business flows. In this oversimplified situation, there are only two programs, each with one project. If the session speaker were working on the Plantheon program, his idea works. there is only one business model to create. That nail can be hammered in with a screwdriver. Lucky speaker. Showing Franklin his own business model is a good thing.
But if we are working on the Flitrack program, what do we show Franklin? if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns. He will not benefit and neither will the program. In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?
Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models. The business model that Franklin cares about does not need to be created again. It can come out of the repository. The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program.
Anything less is business analysis, not business architecture.
As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. In some cases the feedback will have been solicited by […]
by: Bill Cason – Troux CTO – July 31st, 2012
Gathering and assessing data can be quite seductive. But it’s the equivalent of modelling the
universe, and it’s a recipe for disaster. In fact if we see any problem today in our EA deployments, it’s that people get so excited they want to gather all their data at once. This is the last of the Top Three common mistakes Enterprise Architects (EAs) make when starting (or re-starting) a program. I call this “Building the Answer Machine” – and it doesn’t work.
In this scenario, you are asking people for more data than you need, without any scope control or business value focus. Obviously you don’t want to collect data, just to see what you can find.
Instead, consider these three recommendations when embarking on a data gathering effort. They will help you successfully identify and gather the data that is most important to your business. #1- Leverage a wider team with a focus on business value to help you identify which data is critical. #2- Automate as much of the data collection process as possible. #3- Market your success internally so that contributors appreciate the fruits of their labor and are more inclined to embrace the data gathering effort moving forward.
Leverage a wider team
You will have lots of stakeholders and constituencies requesting answers. You can quickly lose sight of being able to deliver value in a timeframe that is acceptable to management. Queuing up priorities and managing scope control is hugely important. Otherwise you will have plenty of stakeholders disappointed by your inability to answer their questions.
The EA team is responsible for creating business value with the information that is collected. But don’t waste EA resources gathering that information. With executive sponsorship in place, the enterprise will see it as a priority to identify data stewards. The data stewards will then provide the required data you could not automatically collect. This in turn ensures EA resources are focused on analyzing the quality of the information, and identifying gaps in order to initiate the decision-making process.
Automate data collection process
Based on my team’s experience, as much as 80 percent of the information required to initiate an EA program already exists in the enterprise. In many cases, you can automatically collect important information from other IT and business planning repositories so you don’t have to expend human resources to find what’s already being managed. That said, stay focused on collecting only the information necessary to answer the high priority questions your business wants to address.
Market your success
Don’t forget to market your success internally. You secured support from the organization by promising something good for them, so make sure you go back and tell them you did it. Then the organization as a whole can share in your success.
When you gather all this information and start to see results – in this case the answers to critical business questions – share those results.
Remember, the data acquisition process is accretive. The data you get to answer the first set of questions becomes foundational for answering the second set of questions. You don’t use information, throw it away and stop asking questions. By involving the wider team, you empower and encourage people to embrace the EA processes and use the output to change the business.
We already know that organizational change is one of the hardest challenges any company can embark upon. Ensure you are taking the right steps by aligning a wider team to provide information, automating the data collection process, and marketing your success internally. The EA practice can then deliver true organizational change in a focused and organized manner, on a timeline management expects, and with the support of both your executive sponsor and the whole of the enterprise.
Read other articles in this three-part series: How to avoid common mistakes with your EA Program:
