Search Results for “business model” – Page 56

Link Collection — March 24, 2013

March 24, 2013 by Brenda Michelson

LEAD Frameworks | LEAD Frameworks, Methods & Approaches

Speaking of Enterprise Architecture frameworks, this just crossed my radar via Twitter. Just passing it along, not an endorsement as I haven’t had a chance to dig in.

“LEAD is an abbreviation for “Layered Enterprise Architecture Development” and is often used as a synonym to describe the entire LEAD concept. The LEAD Frameworks refers to either the entire LEAD concept, or to a specific LEAD Framework. A certified LEAD practitioner is called a LEAD eXpert or a LEAD Architect.

The LEAD version 3.0 currently consists of 10 frameworks, 6 methods and 4 approaches that are all integrated to each other with supporting maps, matrices and models that can be used for all aspects of enterprise modelling e.g. business model, competencies, value, services, processes, information, applications, data, platforms, infrastructure and cloud as well as for transformation and innovation modelling.”

tags: enterprise_architecture entarch
#ogChat Summary – Business Architecture | The Open Group Blog

I participated in this Business Architecture tweet jam. It was fun and interesting. No surprise, I have a different view than the rest. I’m @bmichelson in the linked post.
“The Open Group hosted a tweet jam (#ogChat) to discuss the evolution of Business Architecture and its role in enterprise transformation. In case you missed the conversation, here is a recap of the event.”

tags: business_architecture business_analysis #entarch #bizarch
Amazon launches “Send to Kindle” button for web publishers and WordPress blogs — paidContent

I added this to elementallinks.com. Look for the “Send to Kindle” icon at the end of my posts. I tested on 3 devices: Kindle Touch, iphone and ipad, works well.

“Amazon is now allowing publishers to add “Send to Kindle” buttons to their websites and WordPress blogs, the company announced on the Kindle blog Tuesday.”

tags: kindle blogs
Taotwit’s Too-Big-To-Tweet: TOGAF Good or Bad? – Definitely Ugly!

Nigel raises some great points on TOGAF and the challenges in applying EA frameworks in the real-world. Not to mention, a world where english is NOT the first language.

“TOGAF just tries too hard and ends up failing on a few counts: it’s too comprehensive to be a usable framework and not specific enough to be a methodology.”

However, Nigel also recognizes that TOGAF is currently the only credible option to get newbies up-to-speed.

So, how do we change that?

tags: entarch enterprise_architecture togaf
Big data in the age of the telegraph – McKinsey Quarterly – Organization – Strategic Organization

Decision-making and authority placed nearest the real-time data, circa 1854.

“Daniel McCallum created the first organization chart in response to the information problem hobbling one of the longest railroads in the world. In surprising contrast to today’s top-down organization pyramids, in McCallum’s chart the hierarchy was reversed: authority over day-to-day scheduling and operations went to the divisional superintendents down the line, who oversaw the five branch lines of the railroad. The reasoning: they possessed the best operating data, were closer to the action, and thus were best placed to manage the line’s persistent inefficiencies.”

Plus, cool 1854 org charts… flow with data.

tags: mckinsey data real-time active-information
The Arguments Your Company Needs – Michael Schrage – Harvard Business Review

What is your company’s most important (current / ongoing) argument? Is it focused on strategy, value or individuals?

“Asked several years ago to describe the most important argument taking place at Walmart, then-CEO Lee Scott immediately replied, “The size of our stores.” The world’s largest retailer was debating just how small its footprints and formats could be while still serving customer needs and its own brand equity promise. That conversation, Scott said, provoked a lot of new thinking and analysis.”

..”All firms have strategies and cultures. But sometimes the quickest and surest way to gain valuable insight into their fundamentals is by asking, “What’s the most important argument your organization is having right now?””

tags: schrange hbr business_analysis

Posted from Diigo. The rest of my favorite links are here.

Humility and the Art of Enterprise Architecture

February 27, 2013 by Nick Malik

As a lot, Enterprise Architects are not terribly humble people. We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with.

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago. I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago. I still agree with my post, but I would certainly use different words today than I used in the past. I am more than willing to admit it.

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed. He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs. Did he go back and create an updated canvas? Nope. He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess).

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake. While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed. The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his “ontological table” to the dust bin.

Neither man will change. They have “legacy” models, with their names attached. To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale. That said, I’m no paradigm of humility, myself.

After all, a truly humble EA would not have written this blog post.

(As my teenage daughter would say: Oh snap, you pwned yourself!)

Agility Through New Technologies

February 25, 2013 by Peter Sjølin

Without the capability of linking application development with the infrastructure such as servers, middleware and network your organization will most likely be in more trouble than the decision-makers think. Information technologies have a profound impact on the organization’s ability to reinvent its business model(s) and the products it produces and since organizations in various industries […]

Enterprise Architecture Roadmap for success: Establish an Enterprise Architecture team

February 11, 2013 by BizzDesign Staff

This is the seventh posting in our “<a title=”Blog series Sven van Dijk and Bas van Gils” href=”http://www.bizzdesign.com/blog/posts/bas-van-gils-and-sven-van-dijk”>Enterprise Architecture Roadmap for success</a>” series. In the previous posting we started to describe actionable steps that an organization needs to take in order to set up Enterprise Architecture. We described how organizations should approach Enterprise Architecture implementation as a project, with clear and confirmed ideas on scope, leadership, budget, and planning. We mentioned the establishment of a project team that will be responsible for an effective execution of the project plans. In this posting we zoom in on some of the characteristics of an Enterprise Architecture team. <div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Roadmap-for-succes-establish-the-team.png” alt=”Roadmap for success: Establish an Enterprise Architecture team” title=”Roadmap for success: Establish an Enterprise Architecture team” width=”600″ height=”375″/>Roadmap for success part 7: Establish an Enterprise Architecture team</div> Building the teamImplementing and evolving an Enterprise Architecture function in the organization requires a whole range of roles with specific characteristics, competences, skills, and qualifications. What the most effective team for a given situation would be depends on many factors. These factors include “hard” ones, such as organization size and structure of the organization, and available resources, but also on “soft” aspects, such as culture and “political atmosphere”. These “soft” aspects are usually established through a long tradition and history, and are thus the more tough ones to change.Building a successful team also depends on the approach and vision for enterprise architecture that an organization pursuits. In one of the first postings of this series we described two extreme approaches: top-down and bottom-up. In a top-down approach the role of enterprise architecture is more focused on supporting high-level decision making on the strategy level. In a bottom-up approach, enterprise architecture is positioned much closer to the actual operations. In this approach Enterprise Architects role is to materialize on synergy among the numerous projects (in-flight, as well as planned) by introducing standards for processes, reference architectures, and governance. In the remainder of this posting we will describe typical Enterprise Architecture team characteristics for both approaches.<h2><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600548-Roadmap-for-succes-build-enterprise-architecture-team.jpg” alt=”Roadmap for success: Building the team” title=”Roadmap for success: Building the team” width=”600″ height=”548″/>Building the Enterprise Architecture team</div></h2><h2>The top-down team</h2>The initiative to establish an Enterprise Architecture function that supports the organization solving the question “how should we organize ourselves” on a higher level often comes from executive levels, i.e. the CIO. The initiative is often driven by a need or feeling that the answer to this question is not yet very well understood, can be diverse and/or complex and the organization needs a multi-perspective, and creative yet structured approach to solve the puzzle. Typical situations could for example be mergers and acquisitions, or when an organization feels that more foundational changes to the business model are necessary in order to survive.The role of enterprise architecture in this approach is to provide better insight in the organization and its high-level constituent parts in terms of people, processes/functions, and technology. Often based on high-level models, Enterprise Architecture supports the definition of the necessary change by providing impacts of suggested changes on the current organization, combines multiple perspectives such as the financial perspective, the risk perspective, the operational perspective, the perspectives from the various areas of the business in terms of location, function, etc.The role and position of Enterprise Architecture in this approach has a number of implications for the members of the team that is responsible for setting up the Enterprise Architecture practice. Because the scope of Enterprise Architecture in this approach is often the whole enterprise, it is an important aspect that the team has to reflect the various areas of business. For larger global organizations this means that the regions need to be represented. Or for diversified organizations, this means that the various lines of business need to be represented. Another important aspect is that members have a broad overview of the architectural landscape for their individual areas. This is why we don’t see many domain architects, such as data, application, or business process specialists on Enterprise Architecture teams in this situation. It is not easy to name typical roles in the top-down Enterprise Architecture team, but in general we could state that in the formal reporting hierarchy they are within a few steps from the CIO.<h2>The bottom-up team</h2>As we have described in one of the first postings of this series, the role and position of Enterprise Architecture in a bottom-up approach contrasts heavily with the top-down approach. In a bottom-up approach, the scope of the change is much more defined in terms of objectives and value, and also it is more clear what the architecture footprint is, i.e. the parts of the organizations on which Enterprise Architecture has an impact (provides value). Often, the Architecture Board was heavily involved in the definition of the objectives, and approach for Enterprise Architecture, now the execution of the plan will be the responsibility of the Enterprise Architecture team. In this situation the Enterprise Architecture team will often detail the approach into a working plan, and the implementation process will be governed with this working plan as starting point. The Enterprise Architecture team will frequently, often as much as every two weeks with the Architecture Board to discuss progress.In this situation, the Enterprise Architecture team requires representation from the various functional areas within the scope of the organization. Often these areas are data, technology, security, application, etc. Important characteristics for Enterprise Architecture team members are seniority and expertise in their area, and also some history in the organization, which is important to more successfully navigate the political waters.Although the task at hand seems much more straightforward for the bottom-up team, there are still plenty of challenges on the road. Especially the “relationship management” part of the task requires sufficient social skills. As mentioned earlier in the series, Enterprise Architecture cannot operate in isolation. Strong relationships need to be established and maintained with customers of Enterprise Architecture, in this approach e.g. mainly the project organization.<div class=”captionImage left” style=”width: 387px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Roadmap-for-succes-bottum-up-team.png” alt=”Roadmap for success: The top-down team” title=”Roadmap for success: The top-down team” width=”387″ height=”331″/>The top-down team</div><h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a title=”E-mail Bas van Gils” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”E-mail Sven van Dijk” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers tooling for Enterprise Architecture. It is scheduled to be posted between 25th February and the 1st of March.

Designing secure organizations. Risk management, Enterprise security management and ArchiMate.

January 21, 2013 by BizzDesign Staff

No one is allowed to enter the building without proper authorization; all incoming e-mail messages are filtered; personal computers that are used to store sensitive data do not have a direct connection to the internet, and therefore cannot be accessed remotely. With these enterprise security rules, we have ensured that our private information is safe, right? Wrong! Cyber-attacks are getting increasingly sophisticated, using a combination of digital, physical and social engineering techniques. A typical example is the so-called “road apple attack”. A would-be intruder “accidentally” leaves a USB flash drive – with company logo – in a public spot such as the company car park. An employee picks it up, and chances are that he will not be able to suppress his curiosity and plug it into his PC. Surprise: the drive is infected with malware which, unless proper measures have been taken, will infect the PC and send sensitive information to the intruder.<img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600395-Risk-Management.png” width=”600″ height=”395″ alt=”” title=””/> Of course, there are several ways to prevent this from happening. The system administrator may decide to completely disable the use of USB drives, but perhaps this is too restrictive, causing employees to find ways to circumvent this. Or perhaps a policy against the use of unverified storage devices suffices, if people are disciplined enough to comply with it… There is no easy way to determine how much security is enough, and how much is too much. In other words, how do we find the optimal position on the trade-off between security, usability and costs?Most of the present-day security and <a title=”risk management, secuirity measures” href=”http://www.bizzdesign.com/consultancy/governance-risk-and-compliance/”>risk management </a>approaches are based on checklists, heuristics and best practices. Security measures are applied in a bottom-up way, often neglecting the social aspects. This may lead to an overkill of preventive security measures, also in cases where cheaper (and less intrusive) curative measures may suffice. On the other hand, less obvious threats or vulnerabilities in the organization may easily be overlooked. <div class=”captionImage left” style=”width: 424px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-security-management-ArchiMate.png” alt=”Enterprise Secuirity Management” title=”enterprise security management, model-based approach ” width=”424″ height=”458″/>enterprise security management, Archimate core</div>To avoid this, we advocate a model-based approach to enterprise security management, in which security aspects are fully integrated in the design chain: from strategy and business model, through enterprise architecture, to the design and implementation of the organization and IT support. For this purpose, risk-related concepts are included in existing architecture and design languages. At the <a title=”enterprise architecture, Archimate” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/”>enterprise architecture</a> level, <a title=”ArchiMate open standard” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/”>ArchiMate</a>, as a broadly accepted open standard (with available tool support) that is suitable to describe business and IT aspects in an integrated way, is an obvious choice. Architectures described in <a title=”ArchiMate goals, principles and requirements” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/”>ArchiMate</a> can be linked to goals, principles and requirements, and to detailed design models expressed in languages such as BPMN or UML. The resulting models provide the input for risk and vulnerability analysis, highlighting the areas in the architecture that are most susceptible to attack. In addition, they will guide the design of effective and efficient security measures.With this approach, <a title=”Bizzdesign the Netherlands Contact” href=”http://www.bizzdesign.com/contact/netherlands/”>BiZZdesign</a> can help you to design a secure organization – without unduly restricting your people in their daily work.

Mastering the Enterprise

January 16, 2013 by John Gøtze

In September 2013, the IT University of Copenhagen opens a new Master of Science degree program in Digital Innovation and Management (Cand.it. E-Business). The program will offer three specialization tracks: Process Innovation and New Business Models Digital Governance and Enterprise Architecture Global Relations and Work Processes The second track is of course “my” track. There are …read more

Steps To Create a Core Diagram

December 19, 2012 by Nick Malik

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post. I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco. Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort. Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

Collect a list of your organization’s business models
Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
Make an educated guess about the operating model of the company
Draw the core diagram and build understanding around it

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizations that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

Is Enterprise Architecture accountable for improving customer experience?

October 2, 2012 by Nick Malik

A recent experience with poor customer service has got me thinking about the role of EA in addressing customer experience issues.

One of the last things I was working on, while still in Microsoft IT, was working on an initiative to systematically help improve customer experience. With that experience fresh in mind, I was dealing with an issue with my Tivo DVR today where the Tivo box started to misbehave. I began a chat with their representative and the experience was less than ideal. (If someone from Tivo wants to chat, just drop me a line for details).

That got me thinking. Can EA help? In general, can EA be part of the solution to problems caused by poor customer experiences?

Customer Services is important to the success of any organization

First off, I’d like to say that customer experience is one of the most important elements of the highly competitive online world. The Web has made it very easy for customers to abandon their existing relationships and switch to new ones. Even the slightest provocation can send a customer in search of a competitor, and the features of a product are not as “sticky” as they once were. It is increasingly easy for new small companies to appear that copy all of the key features of a technology and release a competing product, sometimes within a few months of the first one. The results can be fierce competition that, unfortunately, is often addressed in courtrooms instead of the marketplace (Samsung vs. Apple, Google vs. Microsoft, Apple vs. Microsoft, etc.).

Some companies will not pay proper attention to their customer’s experience. This is fairly common, especially in manufacturing companies where there are both software and hardware components involved. For some reason, the fact that two different engineering teams are involved often produces a disjointed experience. (Apple has been leading the way in addressing these kinds of problems. The rest of us need to do so as well).

What are the questions you must always be ready to answer? (The Ten Strategic Questions)

In general, an Enterprise Architect assists with the development of strategic alignment, not by deciding what is important, but making sure that executives don’t miss the important stuff while they are overwhelmed with the mundane. One way to anchor your analysis to ensure that YOU don’t miss the important stuff is to consider some of the high level tools suggested in traditional strategic analysis… tools like SWOT analysis, Five Forces analysis, and partner accountability mapping. However, most of those tools do a poor job of considering the importance of customer experience to enterprise success.

The model that I use is the EA metamodel behind business models. In a prior post, I created a rationalized ontology for the business model canvas that addressed the gaps left by Osterwalder in his analysis. However, in keeping with the effort to make that kind of model useful, I followed the pattern of Osterwalder and created a visual table that represented the corrected business model ontology.

The guidance that you can get from this is to look at each of the blocks in the canvas and consider the possibility that you have not missed anything important in that block. Therefore, if you use this model, you would ask the following ten questions:

Are we targeting the right customers for the growth that we need? (Customer Profile)
Do we have a good understanding of what our customers want and need? (VOC)
Do we have a compelling value proposition to address the needs and demands of those customers? (Value Proposition)
Are we developing products and services that deliver on our value proposition, or is there a gap in our products and/or services that we need to address? (Products and Services)
Have we considered all of the channels we should be using, or are we using too many channels, to distribute our products and services to our customers? (Channels)
Do we have a good idea of the resources we need to deliver on our value proposition? (Resources)
Do we know how to use our resources sufficiently well to produce the results that customers expect? (Required Competencies)
Have we addressed all the cost and revenue implications of the resources, competencies, and channels that we’ve selected? (Cost and Revenue Models)
Are we reaching our customers in the geographies and locales in which they live and work, and if not, why not? (Geographies and Locales)
Have we relied on partners in the right way, leveraging their strengths and the cost implications of using them without opening ourselves to problems of key dependencies? (partner profiles)

This list of questions includes the core questions that we need to be asking in order to address customer experience issues at the strategic level. This is a far more comprehensive list that “5 forces” or “SWOT” and will help you to ensure that you are not missing anything.

How does Enterprise Architecture address customer experience?

The actual experience of a customer is a function of their needs and your products. If a customer needs to drive a nail, a hammer will do. If the customer needs to drive their car to an unfamiliar place, then a Global Positioning System with turn-by-turn directions would be more compelling. If you offer the customer a product that does NOT meet their needs (like a GPS that only shows maps, but doesn’t tell the driver where and when to turn), then they will not be loyal to the product. Their experience will be poor and they will quickly find better products.

Customers don’t want ten inch drills. They want ten inch holes.

When doing a strategy workshop, it is best for the Enterprise Architect to walk in to the workshop with all their preparation in place. Walking in unprepared will produce really poor results. To be prepared, the Enterprise Architect will have already collected the list of “proposed strategies” for the coming period and will have analyzed those strategies from the standpoint of the organization’s business model(s). In other words, for each of the questions above, which ones are being answered by strategy. Now, for the kicker, which ones are not?

Customer experience may already be covered by a strategy, and if it is, you have to do very little. Simply make sure that everyone sees the relative value of that strategy when compared to others (like reducing costs or negotiating new boundaries with existing partners). That is not simple, but not as difficult as the alternative: no strategy for customer experience.

On the other hand, let’s assume that there are goals, or objectives, or themes (rarely actual strategies) already articulated that address the other areas of business model considerations, like costs, or products, or partners. Address the lack of customer focus in your interviews PRIOR to the strategic workshop. Ask your key stakeholders what their customers need. Specifically don’t ask for how those needs are being met… ask what the needs are! Make sure that you plant, in the minds of your stakeholders, the seeds of doubt: do we KNOW what our customers want and need? Is it written down? Would our customers agree with what we wrote down?

During the workshop, propose an initiative to capture the needs of the customers (of each business model) and to map the products and services to those needs. This will let you answer the question: are our products and services meeting the needs of customers? This may involve the development of user personas, scenarios, and competitive surveys. This initiative, when complete, will provide the ammunition that you will need later to propose initiatives to address customer experience gaps.

Note that gaps can exist in many places… not just in the products themselves, but also in the customer service experience that occurs when customers are not happy with their products or have an issue with them.

Conclusion

Enterprise Architecture is a strategic planning function that uses a methodical scientific approach to address the gaps between the goals of a business and the execution of strategy needed to reach them. Using the TEN STRATEGIC QUESTIONS above, Enterprise Architects can capture opportunities and oversights that senior executives may miss. One of those key questions addresses customer experience issues.

Therefore, when an organization fails to deliver good customer experiences, Enterprise Architecture, when used properly, can help to address the situation.

Implementing SOA through TOGAF 9.1: the Center Of Excellence

October 1, 2012 by Serge Thorn

Service-oriented architecture (SOA) has at times been challenged but is now on the verge of mainstream acceptance. It now shows maturity, success and even signs of popularity. Service Oriented Architecture (SOA) is an enterprise scale architecture for linking resources as needed. These resources are represented as business-aligned services which can participate and be composed in a set of choreographed processes to fulfil business needs.

The primary structuring element for SOA applications is a service as distinct from subsystems, systems, or components. A service is an autonomous and discoverable software resource which has a well defined service description.

SOA is based on a fundamental architectural model that defines an interaction model between three primary parties, the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker is the third party who provides and maintains the service registry in addition to providing mediation services between providers and consumers.

In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We’re now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Also many enterprise architects are wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.

To be successful in implementing a SOA initiative, it is highly recommended that a company create a Center of Excellence and the Open Group clearly explains how this can be achieved through the use of TOGAF 9.1. This article is based on the specification and specifically the section (in italics) 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.

I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.
The figure below illustrates below a SOA Center of Excellence as part of the Enterprise Architecture team with domain and solution architects as well as developers, QAs and business architects and analysts coming from a delivery organization.

This center of excellence support methodologies, standards, governance processes and manage a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.
Below is then what is written in the TOGAF 9.1 specification.

A successful CoE will have several key attributes:

A clear definition of the CoE’s mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.

Any SOA Center of Excellence must have a purpose. What do we want to achieve? What are the problems we need to solve?

It may sound obvious, but having a blueprint for SOA is critical. It’s very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.

In order to realize the vision of SOA the following topics should be addressed:

· What to build: A Reference Architecture
· How to build: Service-Oriented Modeling Method
· Whether to build: Assessments, roadmaps, and Maturity evaluations
· Guidance on Building: Architectural and Design patterns
· Oversight: Governance
· How to build: Standards and Tools

The Center of Excellence would first have a vision which could be something like:

“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.

Then a mission statement should be communicated across the organization. Below a few examples of mission statements:

“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”
“The mission of the COE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The COE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”

The Center of Excellence would also define a structure and the various interactions with
· the enterprise architecture team
· the project management office
· the business process/planning & strategy group
· the product management group
· etc.

And create a steering committee or board (which could be associated to an architecture board).

They will provide different types of support:

· Architecture decision support
     o Maintain standards, templates and policies surrounding Integration and SOA
     o Participate in Integration and SOA design decisions
· Operational support
     o Responsible for building and maintaining SOA Infrastructure
     o Purchasing registries and products to grow infrastructure
· Development support
     o Development of administrative packages and services
     o Develop enterprise services based on strategic direction

Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.

Measurements and metrics will have to be identified. The common ones could be:

· Service revenue
· Service vitality
· Ratio between services used and those created
· Mean Time To Service Development or Service change
· Service availability
· Service reuse
· Quality assurance
· Etc.

The CoE will provide the “litmus test” of a good service.

Clearly comprehensive testing activities must be described by the Center of Excellence. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.

This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols including: (here a few examples) HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.
Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.

The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.

The Center of Excellence will promote best practices, methodologies, knowledge, and pragmatic leading-edge solutions in the area of SOA to the project teams.

Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.

This may sounds like a good idea but I have never seen this as an applied practice.

Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.

Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications but it is a culture change within the enterprise which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:

· Enterprise Architecture
· Value of SOA
· Governance model for SOA
· Business Process Management and SOA
· Design of SOA solutions
· Modeling
· Technologies and standards
· Security
· Business communication
· Etc.

It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.

Close-out plan for when the CoE has fulfilled its purpose.

Here again, I am not sure that I have observed any Center of Excellence being closed…
The Center of Excellence will then also define a Reference Architecture for the organization.

A Reference Architecture is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.

The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.

A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.

Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.

The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.

The center of Excellence needs also to define the SOA life cycle management which consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.
Simply put, without management and control, there is no SOA only an “Experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.

For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.

These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment. This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.

The “Principle of Service orientation” must exist as defined in 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition, are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.

SOA principles should be clearly related back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:

· Put the computing near the data
· Services are technology neutral
· Services are consumable
· Services are autonomous
· Services share a formal contract
· Services are loosely coupled
· Services abstract underlying logic
· Services are reusable
· Services are composable
· Services are stateless
· Services are discoverable
· Location Transparency
· Etc.

Here is a detailed principle example:

· Service invocation
     o All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
     o The only exception to this principle will be when the service meets all the following criteria:
          § It will be used only within the same application silo
          § There is no potential right now or in the near future for re-use of this service
          § The service has already been right-sized
          § The Review Team has approved the exception

As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:

· Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
· Service design (SOAD, specification, Discovery Process, Taxonomy)
· Service provisioning (SPML, contracts, SLA)
· Service implementation development (BPEL, SOAIF)
· Service assembly and integration (JBI, ESB)
· Service testing
· Service deployment (the software on the network)
· Service discovery (UDDI, WSIL, registry)
· Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
· Service consumption (WSDL, BPEL)
· Service execution (WSDM)
· Service versioning (UDDI, WSDL)
· Service Management and monitoring
· Service operation
· Programming, granularity and abstraction
· Etc.

Other activities may be considered by the Center of Excellence such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.

As described in TOGAF 9.1, the Center of Excellence can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.

The Center of Excellence provides expanded opportunities for organizations to leverage and re-use service oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.

Implementing SOA through TOGAF 9.1: the Center Of Excellence

October 1, 2012 by Serge Thorn

A clear definition of the CoE’s mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.

Any SOA Center of Excellence must have a purpose. What do we want to achieve? What are the problems we need to solve?

In order to realize the vision of SOA the following topics should be addressed:

The Center of Excellence would first have a vision which could be something like:

“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.

Then a mission statement should be communicated across the organization. Below a few examples of mission statements:

And create a steering committee or board (which could be associated to an architecture board).

They will provide different types of support:

Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.

Measurements and metrics will have to be identified. The common ones could be:

The CoE will provide the “litmus test” of a good service.

The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.

The Center of Excellence will promote best practices, methodologies, knowledge, and pragmatic leading-edge solutions in the area of SOA to the project teams.

Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.

This may sounds like a good idea but I have never seen this as an applied practice.

Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.

It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.

Close-out plan for when the CoE has fulfilled its purpose.

Here again, I am not sure that I have observed any Center of Excellence being closed…
The Center of Excellence will then also define a Reference Architecture for the organization.

The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.

The “Principle of Service orientation” must exist as defined in 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Here is a detailed principle example:

As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:

Link Collection — April 29, 2012

April 29, 2012 by Brenda Michelson

When Will this Low-Innovation Internet Era End? – Justin Fox – Harvard Business Review

Provocative view. Lots of good linked content.

“It’s an age of unprecedented, staggering technological change. Business models are being transformed, lives are being upended, vast new horizons of possibility opened up. Or something like that. These are all pretty common assertions in modern business/tech journalism and management literature.

Then there’s another view, which I heard from author Neal Stephenson in an MIT lecture hall last week. A hundred years from now, he said, we might look back on the late 20th and early 21st century and say, “It was an actively creative society. Then the Internet happened and everything got put on hold for a generation.””

tags: internet neal-stephenson innovation
Citigroup’s massive scalability challenges, by the numbers – Cloud Computing News

Massive scale measured in business terms: trillions of $

“$12.5 trillion. That’s the amount of customer money for which Benjamin’s half of Citi is responsible. About a quadrillion dollars worth of transactions flow through his system every year.”

tags: scalability citi
The Creative Monopoly – NYTimes.com

“[Thiel’s] lecture points to a provocative possibility: that the competitive spirit capitalism engenders can sometimes inhibit the creativity it requires.

Think about the traits that creative people possess. Creative people don’t follow the crowds; they seek out the blank spots on the map. Creative people wander through faraway and forgotten traditions and then integrate marginal perspectives back to the mainstream. Instead of being fastest around the tracks everybody knows, creative people move adaptively through wildernesses nobody knows.”

Now think about the competitive environment that confronts the most fortunate people today and how it undermines those mind-sets.

tags: creativity economics competition
Beyond the 10,000 Hour Rule: Richard Hamming and the Messy Art of Becoming Great

“”Great scientists tolerate ambiguity very well,” Hamming says. “They believe the theory enough to go ahead; [but] they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory.”

This is perhaps the most important advice from among Hamming’s many suggestions. The path to excellence requires this balance between confidence and doubt, and though this balance is challenging, it’s tractable so long as your recognize what you’re facing.”

tags: expertise talent
The Flight From Conversation – NYTimes.com

“WE expect more from technology and less from one another and seem increasingly drawn to technologies that provide the illusion of companionship without the demands of relationship. Always-on/always-on-you devices provide three powerful fantasies: that we will always be heard; that we can put our attention wherever we want it to be; and that we never have to be alone. Indeed our new devices have turned being alone into a problem that can be solved.”

tags: sherryturkle technology society

Posted from Diigo. The rest of my favorite links are here.

End of "High Street Retail" As We Know It…..

March 28, 2012 by Amitabh Apte

More than 2,000 UK jobs were axed yesterday, as Game Group closed hundreds of shops after the company collapsed into administration. The beleaguered video games retailer, which had 610 UK stores, was unable to meet a £21m second-quarter rental payment due on Sunday and appointed the accountancy firm PwC as administrator. Is this the end of “High Street Retail” as we know it? Is it the beginning of the end?

The writing was on the wall for Game for some time now. Earlier this month,the struggling video games retailer had confirmed that a number of its suppliers were refusing to do business with the company, sending its shares down 63% to 1.29p. Back then Game said that while it was trying to resolve the matter “as quickly as possible”, it was unsure if its efforts would be successful.

The Game is not the only retail business struggling for the past few years. Almost all high-street retailers have recorded reduced operating margins and profits, if at all they were there. The difficulties at Game are testament to the current squeeze on living costs coupled with a change in shopping habits and games technology. The group has also been battered by competition from cheaper rivals on the internet, such as Amazon and Play.com, and the major supermarkets. Separately, many people now download game Apps direct to tablets or smart phones, rather than buying software to be loaded in to consoles like the PlayStation, xBox on Nintendo Wii.

What the Game story tells us however is something unique where a Technology brand is being eaten by fast evolving technology business models. As Matthew Warman states in the Telegraph, “the story of Game is simply the first taste of what the web is doing to global retail – its products happen to be bought by users who migrated quickly to the web. All other specialist retailers are being challenged online: Whittards, to take just one example, is under pressure from specialist tea and coffee retailers such as Teahorse and Kopi, who will send subscribers superb selections every month, and cater to profitable, premium niches yet don’t have the overheads of high street rents and other associated costs. Many consumers simply see that they don’t have the inconvenience of shopping. Where Game led, even the most aromatic of products is set to surely follow.”

It was not so long ago that another high-profile retail venture went bust in the UK. It was in November 2011 that, Carphone Warehouse announced that it was to close all of its 11 Best Buy stores across the UK. The first Best Buy store in the UK only opened in April of last year. But the outlets failed to make a profit. Carphone Warehouse and Best Buy initially planned to open 200 Best Buy stores across the UK and continental Europe. But clearly they had to abandon those plans well and truly before they could take-off. Is there market left for technology shopping on UK high-street? Probably there is and there will be always that small niche segment of shoppers who prefer to touch their electronic goods, CDs, Games and likes before they buy them. But that segment is shrinking all the time and internet players will certainly be calling the shots in this segment of Retail market.

Search Results for: business model

Link Collection — March 24, 2013

Humility and the Art of Enterprise Architecture

Agility Through New Technologies

Enterprise Architecture Roadmap for success: Establish an Enterprise Architecture team

Designing secure organizations. Risk management, Enterprise security management and ArchiMate.

Mastering the Enterprise

Related Posts:

Steps To Create a Core Diagram

Is Enterprise Architecture accountable for improving customer experience?

Customer Services is important to the success of any organization

What are the questions you must always be ready to answer? (The Ten Strategic Questions)

How does Enterprise Architecture address customer experience?

Conclusion

Implementing SOA through TOGAF 9.1: the Center Of Excellence

Implementing SOA through TOGAF 9.1: the Center Of Excellence

Link Collection — April 29, 2012

End of "High Street Retail" As We Know It…..