Search Results for “business model” – Page 163

Enterprise Architecture Lifecycle

June 27, 2013 by Adrian Campbell

The Enterprise Architecture team has a lifecycle of its own, but doesn’t operate in a vacuum. The Enterprise Architecture capability fails if it is seen too much as blue sky thinking in an ivory tower. The Enterprise Architecture team will interact closely with all the other management processes in an organisation, especially the IT management […]

Enterprise Architecture: A definition and implementation checklist.

June 27, 2013 by Kim Parker

In order to reap maximum value from the recognition that an Enterprise Architecture can provide long lasting and continuous business benefit the decision to build and use one must be made. How to do so is where some businesses come … Continue reading →

Cloud: The Testing Ground for the New CIO

June 26, 2013 by Chris Curran

Guest post by: Mike Pearl In case you missed it, Michael Hickins of the Wall Street Journal recently detailed a lively panel discussion that unfolded during MIT’s CIO Symposium on May 22, 2013. CIOs complained in chorus about cloud computing vendors circumventing the IT department and selling directly to business units. One CIO compared the proliferation of rogue cloud deployments to cockroaches. In the midst of the fiery finger pointing and complaints about redundancy, complexity, […]

If you liked this, you might also like:

Building Blocks of Your Enterprise Mobile Strategy

June 20, 2013 by Amitabh Apte

Given my current focus on Multi-Channel architecture & technology programs for Retail and Logistics customer in UK&I, I am often on a look out for new ideas, trends and business case studies. This interest took me to the IBM Enterprise Mobile Summit earlier this week in London Southbank. It was a compact but impressive gathering of Mobile industry experts, suppliers and consumers. It did help me crystallize my thoughts around Enterprise Mobile Strategy which I am trying to summarize in this blog post.

When an Enterprise (commercial organisation) makes an investment decision to develop a Mobile Strategy (e.g. Mobile Applications or Apps) and related products or services, it should do so based on strategic enterprise intent (or in certain instances tactical response). This investment should take into account a number of stakeholder perspectives such as Functional, Development, Delivery, Operations, End-User Consumer and the Market.

IBM MobileFirst

The Strategic Intent and drivers behind Enterprise Mobile Investment –
Before committing funds on Mobile strategy a valid question to ask is, what is your Enterprise attempting to achieve by mobile investment? For instance do you see mobile evolving as one of your primary channel to market? Are you attempting to gather insights from mobile data which may provide new opportunities for product and services expansion?

Or are you simply trying to increase your business transactions though Mobile media. In some instances it may be seen as a media for extending the brand experience for more personal shopping or browsing experience.

The Enterprise Functional Perspective – If the purpose of Mobile strategy is to address internal organisation efficiency then the functional objectives need to focus on employee and organisation productivity enhancement. For instance how can a Mobile App transform, optimise internal work flow and may be also enhance the customer interactions. KPIs here could be reduction of complexity, reduction in wastage, improving quality, faster time to market etc. As I observed in IBM session, some of IBM customers are using the Mobile strategy to extend Enterprise business network in new ways. For instance an Italian organisation leveraged Mobile Apps to find promotions in their network and connected people to these promotions. Michael Gilfix of IBM in this session also cited IBM’s own example of how Mobile strategy is driving next level of productivity by acknowledging its global workforce segmentation.

The Development Lifecycle Perspective – During the session both Michael Gilfix of IBM and Jessica Figueras, a Mobile Industry Analysthighlighted a point that there is a difference between creating conventional Apps and Mobile Apps. Mobile development and developers need to understand the Mobile App consumption patterns, workflows and user interaction in different ways. IBM briefly shared their Mobile Development Lifecycle process which comprises of iterative phases such as; Design & Develop, Instrument, Integrate, Test, Scale & Certify, Deploy, Manage, Obtain Insight and back to Design & Develop. Jessica made a good point that Mobile Apps are becoming more and more complex and they need Enterprise Architecture underpinning them to be successful.

The IT Delivery and Operations Perspective – The above point about Enterprise Architecture requirements extends into the Operational and Delivery aspects of IT too. Challenge of Fragmentation is particularly important; how best to serve different fragmented devices to serve multi-channel experience which is a different challenge that Web Apps where one size often fits all consumers. Michael was also keen to point our Security and Access control aspects such as Loss of control over distribution, impact of BYOD, Control of data and access as code often would run in environment outside of Enterprise control. From the customer satisfaction perspective, the end-user of Mobile Apps will look out for and increasingly expect consistent multi-channel experience. e.g. Airline – phone, kiosk, in-flight, travel experience.

The consumer perspective: Creating compelling mobile user experience – Ali Al-Shakarchi, the UX Architect and Strategist from IBM had some very interesting themes on this perspective which can be argued as the most important factor to make Mobile strategy successful. He highlighted the fact that, user expectations are high and user tolerance is low when it comes to Apps as the competition is fierce, an alternative App is a tap away. Some of the tips which Ali shared were; Stay Relevant, Keep it simple, Build richer experience, Think innovation, Optimise for mobile, Create end to end experience, Be more social and evolve on an ongoing basis in a smart way.

Some of the demos / case studies during the session further underlined some of above points. The Barclays Pingit case study and how it is driving the C2C is a prime example of how Apps can bring success and create new Operating Models for large Enterprises. While the Tealeaf demo effectively showcased the power of analytics behind smart Mobile strategy.

One of the key takeaway for me was, “Why limit Mobile conversations to IT? Focus must be on exploring business opportunities & enhancing business capabilities”. Iwould like to congratulate IBM for putting together a smart, effective and useful summit. I certainly hope to apply some of the above lessons learnt for my customers in Retail and Logistics in near future.

For more on IBM Mobilefirst read here

Building Blocks of Your Enterprise Mobile Strategy

June 20, 2013 by Amitabh Apte

IBM MobileFirst

EA Roadmap for success: Wrap up

June 20, 2013 by BizzDesign Staff

This posting wraps up our blog series on Enterprise Architecture implementation. In the series we described our experiences with implementing enterprise architecture, and how to be successful with that. We followed a step wise structure: Aim, Establish, and Execute. The structure and the postings that are part of this series are depicted in the figure below.<img alt=”Roadmap for success” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130508_EA-Roadmap-for-success-Wrap-up/Roadmap-for-success-wrap-up.png” style=”width: 676px; height: 422px;” title=”Roadmap for success: Final blog”/><h2>Roadmap for success: an overview</h2>Enterprise architecture can be a powerful tool, mostly if an organization has clear ideas and plans as to how enterprise architecture is going to deliver value to the organization. We described that enterprise architecture can benefit an organization in many ways, and that there are several approaches, the extremes being the top-down and bottom up approach. In a top-down approach enterprise architecture helps the organization plan for change on a more strategic level. In a bottom-up approach enterprise architecture can achieve better coordination and coherence among projects and application portfolios by leveraging enterprise architecture practices such as standards and principles. Whatever the approach is, enterprise architecture can never operate in isolation. enterprise architecture processes need to be explicitly aligned with other processes and frameworks in the organization. Often, implementing enterprise architecture is more about reusing, coordinating and leveraging existing processes, rather than introducing exclusively brand new ones. For the task of coordinating enterprise architecture work, the Architecture Board plays an important role. The way in which the architecture board should be organized and operate differs somewhat depending on the approach that the organization takes (<a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-top-down-versus-bottom-up-architecture/”>i.e. top-down or bottom-up</a>) describes all the details.There are a number of Enterprise Architecture frameworks that could be used by an organization as a starting point for the organization specific enterprise architecture framework. These frameworks differ in scope and level of detail. We think the TOGAF standard (The Open Group Architecture Framework) is very complete, especially when combined with ArchiMate (also by the Open Group). ArchiMate can be used to model the Enterprise Architecture. Using ArchiMate, the viewpoints for various stakeholders as described in the TOGAF standard can be created. Independent of what framework an organization chooses it is of importance to tailor it to organization specifics. The framework should never be the goal in itself.In the establish phase we covered a number of aspects such as project based implementation, how to <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-establish-an-enterprise-architecture-team/”>establish the team</a>, <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-tooling/”>what tools</a>(e.g. modeling tools) to use, and whether or not to use <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-consultants/”>consultants</a> to assist in the establishment of the enterprise architecture practice in the organization. Very important is, especially since the word enterprise architecture often comes with humongous expectations, to make sure that enterprise architecture implementation is broken up into pieces that the organization can absorb. We talk rather about evolution of the enterprise architecture practice, where an organization builds the enterprise architecture practice from the situation today, gradually introducing more enterprise architecture tasks and expanding scope and footprint. This approach lets the organizations enterprise architecture maturity grow steadily.So trying to boil the ocean often does not prove to be a successful strategy for enterprise architecture implementation, following a sustainable growth path does.In the last section of the series we covered concrete aspects of doing EA, such as defining <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-architecture-principles-and-models/”>architecture principles and modeling</a>, <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-governing-projects/”>project governance</a>, and <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-capability-based-planning/”>capability base planning</a>.<h2>Learn more</h2>We think we touched upon important aspects of enterprise architecture implementation throughout this series. Of course there is a lot more to learn about Enterprise Architecture, implementation, modeling etc. BiZZdesign offers a number of courses on these subjects, for example training and certification in TOGAF and ArchiMate. Please see our web site for more information and dates. Also, we frequently run webinars on enterprise architecture and other topics in the Business Design field. Dates and more information can also be found on our website: <a href=”http://www.bizzdesign.com”>www.bizzdesign.com.</a><h2>Contact us</h2>If you’d like to know more, please contact the authors directly at <a href=”http://b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a href=”http://s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment.

BIG DATA: Integration in Sheep’s Clothing?

June 19, 2013 by Corey Balko

In part 5 of “Memoirs of an Enterprise Architect” I discussed how to maximize value from the CMDB by integrating it with Troux. In Part 6, I will continue discussing integration and how it relates to Big Data.
More Data…
Do you ever get overwhe…

Data Management 4: Data Stewardship

June 17, 2013 by BizzDesign Staff

This is the fourth blog post in the Data Management series. So far we have discussed Entities and the way they are realized in applications / information systems. This time we zoom in on Data Stewardship.<img alt=”The fourth blog in the Data Management series” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-management-stewardship.png” style=”width: 501px; height: 334px;” title=”Data Management part 4: Realization of Entities in applications”/><h2 class=”p1″>Theory</h2>The Data Steward is a key role in successful Data Management. To put it more strongly, we will argue that without a Data Steward (or Steward, in short) most Data Management initiatives are doomed to fail. <img alt=”Data Steward. Data Management” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-management-data-steward.png” style=”width: 251px; height: 188px; float: left;” title=”The Data Steward is a key role in successful Data Management”/>The steward is an organizational role. The professional tasked with this role is typically responsible for data quality of the Entities in a Subject Area from a business perspective (in a recent talk at the Master Data Management/Data Governance summit in London, Analiese Polsky of SAS mentioned five models for stewardship. However, stewardship aroundinformation areas is still the predominant approach which is why we adopt it here).In some cases a Subject Area is too large for one Steward to manage, and therefore it becomes a joint responsibility of a group of Stewards.The Steward works with Data Professionals (i.e., IT staff) to make sure those requirements with respect to data are realized in an effective manner. Typical tasks for the Steward are: data modeling, data definition, data quality requirement specification and data quality improvement, reference and master data management. It should be noted that a Steward is not a technical role. On the contrary: it is a prototypical business role. Deep business knowledge is essential to be able to articulate business needs with respect to information, and to negotiate the priorities with fellow stewards and IT, resolve conflicts in semantics, budget, and availability of staff etcetera.In order to co-ordinate the work between data stewards, many organizations typically have a Data Council at the Enterprise level. This is where alignment issues are resolved and where strategic decisions with respect to data management are made. If necessary (especially in larger organizations), a level of stewardship can be created in between as illustrated by the following diagram that was taken from the <a href=”http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/”>DAMA DMBOK</a>:<img alt=”DAMA DMBOK Data Management” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-Management-stewardship-DAMA-DMBOK.png” style=”width: 699px; height: 484px;” title=”Stewardship can be created in combination with the DAMA DMBOK”/><h2 class=”p1″>Modeling</h2>This topic does not require a lot of specialized modeling constructs. The most important one is to be able to represent the fact that a Steward is responsible for a Subject Area / Entity / Data Object. The standard way of modeling would involve a BusinessRole for the Steward, assigning it to a BusinessProcess that has access to the relevant passive structure elements. In terms of visualization this is often too complex. We have found that a shorthand notation where a BusinessRole (the Steward) is associated to the BusinessObject (for SubjectArea or Entity) or DataObject works well for communication purposes. The Data Council can be regarded as a body where stewards collaborate. This should be modeled using the BusinessCollaboration concept using standard ArchiMate notation. To avoid visual complexity, visual nesting (drawing stewards inside the council) is preferred over using graphical relations (i.e., drawing a line between the concepts). In terms of analysis there are some interesting things we could do:<ul><li class=”li1″>Select a Steward and generate a view with all Entities and associated Data Objects that s/he is responsible for</li> <li class=”li1″>Select a Steward and highlight (color? Highlight view?) the Entities and Data Objects that s/he is responsible for</li> <li class=”li1″>Generate a matrix-view that shows Stewards on one axis, Entities on the other axis and the names of the associated Data Objects at the intersection</li> <li class=”li1″>Generate a matrix view that shows Stewards on one axis, Entities on the other axis, and Systems that manage (the C, U, D parts) a Data Object that realizes this Entity in between. </li> <li class=”li1″>Select an Entity or Data Object and highlight (color? Highlight view?) the Steward who is responsible for it</li> <li class=”li1″>Select a System and show with labels which Data Objects are managed in that system, and who the associated Steward is. A format could be “Steward: AAA – DataObject: BBB” </li></ul>Doing this type of analysis is fairly straight forward in most modern ArchiMate tools If you are interested in a demo of this type of functionality in BiZZdesign Architect, please leave us a note!The next posting will be about Master Data Management, one of the corner stones of the field of Data Management. It is often said that “You can do data governance without Master Data Management. You can also do Master Data Management without Data Governance, but that would be a bad idea”. An exciting topic, so stay tuned!

At ‘EA and Systems-Thinking’ conference

June 17, 2013 by Tom Graves

For enterprise-architecture and systems-thinking alike, how can we reach towards the opposite of their too-common anti-pattern – all those endless ‘academic’ arguments on LinkedIn? More to the point, how can we bring it out of the abstract, and down into…

How to measure Enterprise Architecture

June 16, 2013 by Adrian Campbell

What is Enterprise Architecture Enterprise Architecture is essentially a strategic planning discipline for ensuring that all the strategies of an enterprise are well executed. How should we measure it and how it is performing? First it’s best to clearly understand what Enterprise Architecture is and who it is for. Enterprise Architecture bridges the gap between […]

Innovate 2013 — Great EA Track

June 14, 2013 by Lou Varveris

We had a really successful Enterprise Architecture (EA) track at Innovate this year — June 2 thru 6, 2013; our best one yet! EA Birds of a Feather session — EA Best Practices — we had about 80 people in the room. Standing room only. We had 16 EA presentations, most of them by customers […]

Enterprise Architecture Roadmap for success: Capability Based Planning

June 13, 2013 by BizzDesign Staff

This is the 12th posting of the enterprise architecture Roadmap for success blog series, before we wrap it up with an overview in the last posting. We have covered a wide range of topics so far, in this posting we zoom in on one of the most useful techniques in the field of strategic enterprise architecture planning: capability based planning.<div class=”captionImage leftAlone” style=”width: 337px;”><div class=”captionImage leftAlone” style=”width: 600px;”><img alt=”Capability Based Planning” class=”leftAlone” height=”375″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600375-Roadmap-for-success-capability-based-planning.png” title=”12th posting in the roadmap for succes series” width=”600″/>Part 12: Capability Based Planning</div></div>Capability based planning<img alt=”Capability Based Planning” class=”left” height=”139″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage150139-capability-based-planning.png” title=”It may take a long time to realize the architecture” width=”150″/>There are many ways to look at architecture as we have seen in this blog series. Generally, architectures of systems (in the broadest sense of the word) are fairly high level and focus on the fundamental organization of the system as well as principles underlying this fundamental organization.Especially for complex systems, it may take a long time to realize the architecture. Or, to put it in a different light, organizations may be smart and to cater for the fact that their long-term vision may change, deciding to take it one step at a time, allowing for the vision / architecture to change. This also takes into account the fact that organizations already have certain capabilities that they may wish / need to develop further in an incremental fashion. This is where Capability Based Planning kicks in.<h2>Capability Based Planning – the TOGAF™ way</h2>Many definitions for capabilities (and frameworks around capabilities) have been proposed and used in practice. In this post we zoom in on the TOGAF-framework which is fairly well aligned with other capability frameworks. The TOGAF-standard has two definitions for the term Capability, which can loosely be paraphrased with the statement “A capability is an ability that an organization, person, or system possesses”. Capabilities are typically ‘horizontal’ in the sense that they span many lines of business as is illustrated by the figure below (from <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard), but that is not always the case.<img alt=”TOGAF and Capability Based Planning” class=”leftAlone” height=”333″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600333-TOGAF-framework.png” title=”The TOGAF-standard has two definitions for the term Capability” width=”600″/>Two capability definitions in TOGAFThe idea is that an organization’s capability may be at a certain ‘level’ at some point in time. In order to further that capability – conform the Architecture Development Method – a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) before it is actually implemented:<img alt=”Capability, Architecture, Solution model” class=”leftAlone” height=”193″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600193-Screen-Shot-2013-04-26-at-11.32.44-.png” title=”a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) ” width=”600″/>Another important aspect of capabilities lies in the fact that they may have different ‘dimensions’. For example, <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard lists a people dimension, process dimension, and material dimensions for a given capability. In other words, when planning the next increment for our ability (i.e., the goal we want to achieve for this increment in the next ADM cycle), we should consider the ramifications for each of these dimensions.<h2>Modeling support</h2>Given the integration between ArchiMate® and TOGAF™, we feel that capability based planning also deserves proper modeling support. We are working on a simple meta-model to support capability based planning, the core of which looks like this: <img alt=”Capability based planning. A meta model” class=”leftAlone” height=”301″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/core-modeling-ArchiMate-TOGAF.png” title=”meta-model to support capability based planning” width=”422″/>This sample shows that capabilities may have one or more dimensions, and are realized by one of more increments, indicative of the different points in time. These increments are still conceptual in nature, and indicate points in time. Each increment may be realized by an architecture, expressed as a set of core concepts (<a href=”http://www.bizzdesign.com/blog/archimate-core-overview/” target=”_blank”>see our series on ArchiMate</a>). Using this simple meta-model we can create the following view:<img alt=”Capability with 5 different dimensions” class=”leftAlone” height=”299″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage500299-core-concepts-meta-model-ArchiMate-TOGAF.png” title=”Each increment may be realized by an architecture, expressed as a set of core concepts” width=”500″/>Here we see a capability with 5 different dimensions. In each of the four increments, the capability has a certain value that indicates ‘how good we are doing with respect to this capability’. As the analysis of this diagram may be hard, we propose a simple radar view as follows:<img alt=”radar view of capability” class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/customer-dimension-capability-increments.png” title=”Capability radar view” width=”350″/><h2>Use in practice</h2>In our experience, Capability Based Planning as a technique can be used in a many different settings. The main benefit of this approach lies in the combination of easy communication (capability is a term that management tends to understand well) while still allows for formal modeling and analysis. We have used it successfully in helping one of our clients in furthering their data management practice, linking the technique of capability based planning with the DAMA DMBOK framework. The DMBOK framework decomposes the data management capability into several sub capabilities such as data governance, master data management, Business Intelligence and so on. It also proposes to consider each capability from different dimensions which may lead to an assessment such as:<img alt=”Capability assessment” class=”leftAlone” height=”270″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage450270-DAMA-DMBOK-framework.png” title=”such diagrams communicate well and provide a solid basis for further analysis and realization” width=”450″/>Indeed, such diagrams communicate well and provide a solid basis for further analysis and realization (which steps will we take? When? What is the architecture that goes with each of these steps? How does this translate to projects that take us to the next level?).<h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a href=”mailto:b.vangils@bizzdesign.com” target=”_blank”>b.vangils@bizzdesign.com</a> / <a href=”mailto:s.vandijk@bizzdesign.com” target=”_blank”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next wraps up the series! It is scheduled to between 6th and 10th of May.