Search Results for: business model

Digital Razorblades: CIO Insight from App Stores

by

  Razorblades. This was the thought I had while browsing the “top grossing” apps in the Apple AppStore today.  The top 10 grossing apps are “free” and the same is true in the Android store. How could this be?  Well, it turns out that these apps ARE free, but make their revenue by selling add-ons, upgrades, tokens, in-game currency, game equipment, etc.  This is like the razor vs blades business model, in which the razor […]

If you liked this, you might also like:

  1. Outside-In IT: A Preview of PwC’s Digital IQ Results
  2. 7 Digital Strategies of Top-Performing Companies
  3. 4 Considerations When Shopping the Google Apps Marketplace

Building an Enterprise Architecture value proposition using TOGAF® 9.1. and ArchiMate 2.0

by
When introducing Enterprise Architecture as a program or initiative, it is regularly done from an IT perspective rarely considering what the costs will be and if there will be any return on investment. This presents a particular challenge to Enterprise Architecture.

Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements and metrics, KPIs. Going to the solution level, they commonly use indicators such as percentage uptime for systems from the System Management team, error rates for applications from the Development Support team, or number of calls resolved on the first call from the Service Desk, etc. These KPIs usually are defined at an early stage and very often delivered in dashboards from various support applications.

On the other hand it is much more difficult to define and implement quantifiable measure for Enterprise Architecture. Many activities introduced with appropriate governance will enhance the quality of the delivered products and services, but it still will be a challenge to attribute results to the quality of Enterprise Architecture efforts.

This being said, Enterprise Architects should be able to define and justify the benefits of their activities to their stakeholders, and to help executives understand how Enterprise Architecture will contribute to the primary value-adding objectives and processes, before starting the voyage. The more it is described and understood, the more the Enterprise Architecture team will gain support from the management. There are plenty of contributions that Enterprise Architecture brings and they will have to be documented and presented at an early stage.

There won’t be just one single answer to demonstrate the value of an Enterprise Architecture but there seems to be a common pattern when considering feedbacks from various companies I have worked with.
Without Enterprise Architecture you can probably NOT fully achieve:

  • IT alignment with the business goals

As an example among others, the problem with most IT plans is that they do not indicate what the business value is, and what strategic or tactical business benefit the organization is planning to achieve. The simple matter is that any IT plan needs also to have a business metric, not only an IT metric of delivery. Another aspect is the ability to create and share a common vision of the future shared by the business and IT communities.

  • Integration

With the rapid pace of change in business environment, the need to transform organizations into agile enterprises that can respond quickly to change has never been greater. Methodologies and computer technologies are needed to enable rapid business and system change. The solution also lies in Enterprise Integration (both business and technology integration).

For business integration we use Enterprise Architecture methodologies and frameworks to integrate functions, processes, data, locations, people, events and business plans throughout an organization. Specifically the unification and integration of business processes and data across the enterprise, and potential linkage with external partners become more and more important.

To also have technology integration, we may use enterprise portals, enterprise application integration (EAI/ESB), Web services, service-oriented architecture (SOA), business process management (BPM) and try to lower the number of interfaces.

  • Change management

In recent years the scope of Enterprise Architecture has expanded beyond the IT domain and Enterprise Architects are increasingly taking on broader roles relating to organizational strategy and change management. Frameworks such as TOGAF 9.1 include processes and tools for managing both the business/people and the technology sides of an organization. Enterprise Architecture supports the creation of changes related to the various architectures domains, evaluating the impact on the enterprise, taking into account risk management, the financial aspects ( cost / benefit analysis), and most importantly ensure the alignment with business goals and objectives. Enterprise Architecture value is essentially tied to its ability to help companies to deal with complexity and changes.

  • Reduced time to market and increased IT responsiveness

Enterprise Architecture should reduce systems development, applications generation and modernization timeframes for legacy systems. It should also decrease resource requirements. All of this can be accomplished by re-using standards, or existing components such as the architecture and solution building blocks in TOGAF 9.1. Delivery time and design/development costs can also be decreased by the reuse of reference models. All that information should be managed in an Enterprise Architecture Repository.

  • Better access to information across applications and improved interoperability

Data and information architectures manage the organization assets of information, optimally and efficiently. This supports the quality, accuracy and timely availability of data for executive and strategic business decision-making, across applications.

  • Readily available descriptive representations and documentation of the enterprise

Architecture is also a set of descriptive representations (i.e. “models”) that are relevant for describing an Enterprise such that it can be produced to management’s requirements and maintained over the period of its useful life. Using an Architecture Repository, developing a variety of artefacts and modelling some of the key elements of the enterprise; will contribute to build this documentation.

  • Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems

Cost avoidance can be achieved by identifying overlapping functional scope of two or more proposed projects in an organization, or the potential cost savings of IT support by standardizing on one solution.
Consolidation can happen at various levels for the architectures: for shared enterprise services, applications and information, for technologies and even data centers.

This could involve consolidating the number of database servers, application or web servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing and related consolidation initiatives. Consolidation may be a by-product of another technology transformation, or it may be the driver of these transformations.

Whatever motivates the change, the key is to be in alignment, once again, with the overall business strategy. Enterprise architects understand where the business is going, so they can pick the appropriate consolidation strategy. Rationalization, standardization, and consolidation process helps organizations understand their current Enterprise Maturity level and move forward on the appropriate roadmap.

  • More spending on Innovation

Enterprise Architecture should serve as a driver of innovation. Innovation is highly important when developing a target Enterprise Architecture, and realizing the organization’s strategic goals and objectives. For example, it may help to connect the dots between business requirements and the new approaches SOA and cloud services can deliver.

  • Enabling strategic business goals via better operational excellence

Building Enterprise Architecture defines the structure and operation of an organization. The intent of enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. It must be designed to support an organization’s specific business strategies.

Jeanne W. Ross, Peter Weill, David C. Robertson in “Enterprise Architecture as Strategy: Creating a Foundation for Business” wrote “Companies with more-mature architectures reported greater success in achieving strategic goals” (p. 89). This included better operational excellence, more customer intimacy, and greater product leadership (p. 100).

  • Customer intimacy

Enterprises which are customer focused and aim to provide solutions for their customers should design its business model, IT systems and operational activities to support this strategy at the process level. This involves the selection of one or few high-value customer niches, followed by an obsessive effort at getting to know these customers in detail.

  • Greater product leadership

This approach enabled by Enterprise Architecture is dedicated to providing the best possible products from the perspective of the features and benefits offered to the customer. It is the basic philosophy about products that push performance boundaries. Products or services delivered by the business will be refined by leveraging IT to do the end customer’s job better. This will be accomplished by the delivery of new business capabilities (e.g. on-line websites, BI, etc.).

  • Comply with regulatory requirements

Enterprise Architecture helps companies to know and represent their processes and systems and how they correlate; fundamental for risk management and managing the regulation requirements, such as those derived from Sarbanes-Oxley, COSO, HIPAA, etc.

This list could be continued as there are many other reasons why Enterprise Architecture brings benefits to organizations. Once your benefits have been documented you could also consider some value management techniques. TOGAF 9.1 refers in the Architecture Vision phase to a target value proposition for a specific project. Here we would apply the value proposition concept to the Enterprise Architecture initiative as a whole.

Value Management uses a combination of concepts and methods to create sustainable value for both organizations and their stakeholders. Some tools and techniques are specific to Value Management and others are generic tools that many organizations and individuals use. There exist many Value Management techniques such as Cost-benefits Analysis, SWOT Analysis, Value Analysis, Pareto Analysis, Objectives Hierarchy, Function Analysis System Technique (FAST), and more…

The one I suggest to illustrate is close to the Objectives Hierarchy technique, which is a diagrammatic process for identifying objectives in a hierarchical manner and often used in conjunction with business functions. Close, because I will use a combination of the TOGAF 9.1 metamodel with the ArchiMate 2.0 Business Layer, Application Layer and Motivation Extensions Metamodels, consider core entities such as value, business goals, objectives, business processes and functions, business and application services, application functions and components. This approach being inspired by the presentation by Michael van den Dungen and Arjan Visser at the Open Group Conference in Amsterdam 2010 and I’m here adding some Archimate 2.0 concepts.

Firstly the entities from the TOGAF 9.1 metamodel:

Categories Archimate, Business Strategy, business transformation, Enterprise Architecture, IT Business Alignment, Metamodel, Open Group, togaf, Value proposition

Exposing the value of BPM

by

Inefficient processes can make or break your organizations ability to succeed. Each year organizations dish out hundreds, even millions, of dollars leveraging the wrong resources to try and improve ineffective business processes. Companies that are unable to adapt to new industry regulations, changing business models and competitor innovation are facing the reality of failure. The […]

Related posts:

  1. 3 Reasons Organizations Need Capability Maps Organizations are made up of thousands of capabilities, each individually…
  2. Metastorm Teams with Forrester to Shed Light on EA & BPM Disconnect Are BPM and EA aligned in your organization?  On September…
  3. Must See Guide to Forrester Business Process Forum 2011 The Forrester Business Process Forum in Boston, Mass. is just three…

Related posts brought to you by Yet Another Related Posts Plugin.

Link Collection — February 5, 2012

by

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

When Was Your Last Enterprise Architecture Maturity Assessment?

by
Every company should plan regular architecture capability maturity assessments using a model. These should provide a framework that represents the key components of a productive enterprise architecture process. A model provides an evolutionary way to improve the overall process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, managed and mature process. The goal is to enhance the overall odds for success of the enterprise architecture by identifying weak areas and providing a defined path towards improvement. As the architecture matures, it should increase the benefits it offers the organisation.

Architecture maturity assessments help to determine how companies can maximise competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management.

There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the US Department of Commerce ACMM, the Open Group architecture maturity model, and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.

As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).

Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.

Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.

In the following example you may observe four different phases on how to run an assessment.

image

The Phase 1 would include several steps:

  • Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT
  • Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
  • Production of a report
  • Calculation of a maturity score. For the representation, we use the term maturity level or organisational maturity as described below

 
image

Sources

o CMMI for Development (Version 1.2, 2006)
o Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
o The US Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
o TOGAF® 9.1
o NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)

We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).

image

The use of radar may also be a nice way to present the results. (Example below)

image

  • Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis, recommendations
  • Next steps

The Phase 2 would include several steps:

  • Based on results from the Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next (required) level of maturity.
  • The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organisation, it provides a full understanding of the business drivers and organisation issues and a clear view of where the stakeholders want the organisation to be. The outputs of this phase are priorities, and an action plan that is agreed, and understood by the key stakeholders in the organisation. There could also be a target radar diagram as shown below (Example).

image

The updated report may then look like this (extract of an example):

image

The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.

To conduct an evaluation of an organization’s current practices against an architecture capability maturity assessment model, allows to determine the level at which the organization currently stands. It will indicate the organisation’s maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.

When Was Your Last Enterprise Architecture Maturity Assessment?

by
Every company should plan regular architecture capability maturity assessments using a model. These should provide a framework that represents the key components of a productive enterprise architecture process. A model provides an evolutionary way to improve the overall process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, managed and mature process. The goal is to enhance the overall odds for success of the enterprise architecture by identifying weak areas and providing a defined path towards improvement. As the architecture matures, it should increase the benefits it offers the organisation.

Architecture maturity assessments help to determine how companies can maximise competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management.

There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the US Department of Commerce ACMM, the Open Group architecture maturity model, and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.

As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).

Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.

Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.

In the following example you may observe four different phases on how to run an assessment.

image

The Phase 1 would include several steps:

  • Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT
  • Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
  • Production of a report
  • Calculation of a maturity score. For the representation, we use the term maturity level or organisational maturity as described below

 
image

Sources

o CMMI for Development (Version 1.2, 2006)
o Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
o The US Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
o TOGAF® 9.1
o NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)

We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).

image

The use of radar may also be a nice way to present the results. (Example below)

image

  • Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis, recommendations
  • Next steps

The Phase 2 would include several steps:

  • Based on results from the Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next (required) level of maturity.
  • The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organisation, it provides a full understanding of the business drivers and organisation issues and a clear view of where the stakeholders want the organisation to be. The outputs of this phase are priorities, and an action plan that is agreed, and understood by the key stakeholders in the organisation. There could also be a target radar diagram as shown below (Example).

image

The updated report may then look like this (extract of an example):

image

The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.

To conduct an evaluation of an organization’s current practices against an architecture capability maturity assessment model, allows to determine the level at which the organization currently stands. It will indicate the organisation’s maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.

The Art of Enterprise Architecture – Section 12 – The investigation by process

by

The six ways There are six ways of investigating by process. The first is to go by strategic intent; the second is to follow the business models; the third is to go by information need; the fourth is to trace through application usage; the fifth is to trace through the organizations; the sixth is to […]

Multi-Channel Retailing Takes a new Meaning with Retail Apps

by
Retail Reference Architecture, it’s evolution and real-life pragmatic implementations happens to be one of my key interest area. So far on this blog I have discussed the concept of Retail Reference Architecture, proposed a concise yet complete Simplified Retail Reference Architecture and also shared some of the innovations from real-life implementations of Retailers such as ASOS. As a matter of fact I do follow fortunes of ASOS with great interest. To me this is a bold, new take on the science of retailing (…some might call is an Art of Retailing) which combines best practices from innovator’s such as Amazon.com and presents a unique and deceptively simple business model. This post shares some of my further observations about ASOS and more importantly how they continue to lead the innovative use of Information Technology in the retail space.

Since summer ASOS  has launched its App for the Apple range of mobile devices. The new service has been designed for iPhone, iPad and iPod Touch users, and along with the function to ‘save for later’ any item of interest sold by the trader, the app also includes a locator for local drop-off points for customers looking to return unwanted purchases.
Free to download, the new app lets you browse and shop directly from fashion editorials, very similar to Net-à-Porter’s. The app comes with trend reports and also contains content originally produced for the online version of the Asos magazine as well as exclusive footage and features such as video and 360-degree views of clothing items. The iPad app is available for free from the App Store since August this year with both Android and iPhone versions scheduled to launch by the close of 2011. 

As the App design James Davie says, “this App design provided a series of new challenges. Most importantly striking the perfect balance between giving the user the familiar ASOS shopping experience, and the equally familiar iPad navigation experience. The final result is a balance of both which should give the user a quick, painless and enjoyable shopping experience.”  Having personally used this App now I can confirm that this is one of the best fashion retailing App available out there with intuitive navigation, fresh content, catalogue, bold designs and just tons of “coolness”! Above the cosmetics, what stands out for me is the fact that, customer accounts are totally synchronised across all of the retailer’s platforms so whether they are using the new apps, the standard website or the mobile site all of their details will remain consistent.
This App and iPad appear to be made for each other and not just a lift-off from ecommerce site made to fit with iPad format. Just to clarify I am not a regular ASOS shopper but as a keen Retail Technology practitioner and follower…this company and it’s innovation are worth watching!

Multi-Channel Retailing Takes a new Meaning with Retail Apps

by
Retail Reference Architecture, it’s evolution and real-life pragmatic implementations happens to be one of my key interest area. So far on this blog I have discussed the concept of Retail Reference Architecture, proposed a concise yet complete Simplified Retail Reference Architecture and also shared some of the innovations from real-life implementations of Retailers such as ASOS. As a matter of fact I do follow fortunes of ASOS with great interest. To me this is a bold, new take on the science of retailing (…some might call is an Art of Retailing) which combines best practices from innovator’s such as Amazon.com and presents a unique and deceptively simple business model. This post shares some of my further observations about ASOS and more importantly how they continue to lead the innovative use of Information Technology in the retail space.

Since summer ASOS  has launched its App for the Apple range of mobile devices. The new service has been designed for iPhone, iPad and iPod Touch users, and along with the function to ‘save for later’ any item of interest sold by the trader, the app also includes a locator for local drop-off points for customers looking to return unwanted purchases.
Free to download, the new app lets you browse and shop directly from fashion editorials, very similar to Net-à-Porter’s. The app comes with trend reports and also contains content originally produced for the online version of the Asos magazine as well as exclusive footage and features such as video and 360-degree views of clothing items. The iPad app is available for free from the App Store since August this year with both Android and iPhone versions scheduled to launch by the close of 2011. 

As the App design James Davie says, “this App design provided a series of new challenges. Most importantly striking the perfect balance between giving the user the familiar ASOS shopping experience, and the equally familiar iPad navigation experience. The final result is a balance of both which should give the user a quick, painless and enjoyable shopping experience.”  Having personally used this App now I can confirm that this is one of the best fashion retailing App available out there with intuitive navigation, fresh content, catalogue, bold designs and just tons of “coolness”! Above the cosmetics, what stands out for me is the fact that, customer accounts are totally synchronised across all of the retailer’s platforms so whether they are using the new apps, the standard website or the mobile site all of their details will remain consistent.
This App and iPad appear to be made for each other and not just a lift-off from ecommerce site made to fit with iPad format. Just to clarify I am not a regular ASOS shopper but as a keen Retail Technology practitioner and follower…this company and it’s innovation are worth watching!

Why should anyone do enterprise-architecture?

by

A nice quick one this time! I came across this tweet today from business-model guru Alex Osterwalder: business_design: A business model’s performance is due more to the harmonious relationships among its elements than to the elements themselves I tend to describe a core driver for enterprise-architecture and the like as one very simple idea: things […]

The Service Oriented Enterprise

by

It’s now fourteen years since CBDI was formed. In the early days our mission was, as a think tank, to evangelize new ideas of modularity, separation, contract based and service orientation.

We had a vision then; it was the enterprise, every enterprise, as a set of services deployed in a cloud.

Of course over the years we have become immersed in the details of best practice, education, and assisting larger enterprises to leverage and realize the SOA concepts. But the vision is still there.

It was around 2005 that we first started thinking about capability as a formal concept. The first report on the subject was in June 2006, and at that time the CBDIers started a long running debate (well argument actually) about this concept. There were two primary issues. First, should a capability be standalone or could it be an integral part of a broader application and technology infrastructure. In the end we couldn’t agree and we compromised in identifying capabilities as standalone or not standalone. I will admit I was in the first camp, and remain there today.

The second issue was should organizations be planning for the entire enterprise to be comprised of capabilities. To be honest this issue received less attention and in the end we never published advice on this. Perhaps it was just too early. Also in those early days there was confusion over capabilities. Was a capability part of a business process, or did the capability subsume the business process? Well of course these questions have long been resolved with experience.

But whilst the capability concept is now widely understood, I wonder how many enterprises have actually taken it to the logical conclusion and organized (their SOA and indeed the business) around them? I see many pretty capability maps, but fewer capability services.

The reason I am returning to this subject is because many organizations are now rebooting their SOA initiative and they should be looking at capability services as the foundation of their architecture. Why?

1. Business capabilities represent a common perspective shared by business design and service implementation.

2. Properly structured capabilities are completely independent (see above) and facilitate change with the minimum horizon of impact. They also support practical analysis and classification of services as core or context which facilitates the sourcing decisions.

3. Looking at how the world works today, the primary strategy must be around ecosystem collaboration. Choose what capabilities are core to your enterprise and specialize in them. Organize around them. Conversely identify the context capabilities and figure out what collaborations will be most complementary and go make partnerships, or offshore or outsource or rent from the Cloud.

4. Plan to implement the entire core of the enterprise as a set of strategic capabilities that are smart, autonomic, and talk directly to the real “end user”. Eliminate all other process interventions and optimize the core capabilities using the very latest technology. Architect and engineer the capabilities to be capable of continuous evolution.

5. Stop talking about SOA, start talking about the Service Oriented Enterprise. It’s a business issue.

We have dedicated this October 2011 edition of the CBDI Journal to this topic. We advise that business design should be synonymous with capability design. In my report on Business Design for the Service Oriented Enterprise, I explore a series of patterns for the smart, continuously evolving, virtual enterprise. I discuss the convergence of ecosystem automation and autonomics, architecture for continuously evolving business, together with the merger of consumer and business IT and how these will have a profound impact on conventional business models, which will in turn affect business modeling techniques and enterprise architecture. In addition we have in depth reports on Capability, Planning and Analysis.

CBDI Journal October 2011

Business Design for the Service Oriented Enterprise

Capability Planning and Analysis


A week in Tweets: 04-10 September 2011

by

And, for once, not overly late… Another week’s collection of Tweets and links, always the same(ish) structure, always different content. Enterprise-architecture and the kind of big-picture stuff that business will need: tetradian: [post] EA metamodel and method http://bit.ly/q2Qc5R #entarch (thx @ArtBourbon @pbmobi @adraffin @Robert_Phipps) gkathan: RT @jukkaam: Finding Opportunities in Business Model Innovation: business model […]