http://blog.goodelearning.com/archimate/archimate-important-part-enterprise-architects-tool-box/
miércoles, 31 de julio de 2013
martes, 30 de julio de 2013
How to build a Roadmap – Sequence
http://eavoices.com/2013/07/29/how-to-build-a-roadmap-sequence/
An earlier post (How to Build a Roadmap) in this series summarized the specific steps required to develop a well thought out road map. This roadmap identified specific actions using an overall pattern ALL roadmaps should follow. The steps required to complete this work:
- Develop a clear and unambiguous understanding of the current state
- Define the desired end state
- Conduct a Gap Analysis exercise
- Prioritize the findings from the Gap Analysis exercise into a series of gap closure strategies
- Discover the optimum sequence of actions (recognizing predecessor – successor relationships)
- Develop and Publish the Road Map
This post explores the step where we discover the optimum sequence of actions recognizing predecessor – successor relationships. This is undertaken now that we have the initiatives and the prioritization is done. What things do we have to get accomplished first, before others? Do any dependencies we have identified need to be satisfied before moving forward? What about the capacity for the organization to absorb change? Not to be overlooked, this is where a clear understanding of the organizational dynamics is critical (see step number 1, we need to truly understand where we are). 
The goal is to collect and group the set of activities (projects) into a cohesive view of the work ordered in a typical leaf, branch, and trunk pattern so we can begin to assemble the road map with a good understanding what needs to be accomplished in what order.
Finding or discovering the optimal sequence of projects within the larger program demands you be able to think across multiple dimensions recognizing where there may be second and third order consequences for every action undertaken (see the Future Wheel method for more on this). More of craft than a science the heuristic methods I use refer to experience-based techniques for problem solving, learning, and discovery. This means that the solution is not guaranteed to be optimal. In our case, where an exhaustive search is impractical, I think using heuristic methods to speed up the process of finding a satisfactory solution include using rules of thumb, educated assumptions, intuitive judgment, some stereotyping, and lot of common sense. In our case optimization means finding the “best available” 
ordered set of actions subject to the set of priorities and constraints already agreed upon. The goal is to order each finding from the Gap Analysis in a way that no one project within the program is undertaken without the pre-requisite capability in place. Some of you will see the tree diagram image is a Work Breakdown Structure. And you are right. This is after all our goal and represents the end-game objective. The sequencing is used and re-purposed directly into a set of detailed planning products organized to guide the effort.
What to think about
Developing a balanced well-crafted road-map is based on the “best available” ordered set of actions subject to the set of priorities (and constraints) already agreed upon. When you think about this across multiple dimensions it does get a little overwhelming so I think the best thing to do is break the larger components into something we can attack in pieces and merge together later. After this set of tasks is accomplished we should always validate and verify or assumptions and assertions made to ensure we have not overlooked a key dependency.
I’m not going to focus on the relatively straight forward task in the technology (infrastructure) domains many of us are familiar with. Following a simple meta-model like this one from the Essential Architecture project (simplified here to illustrate the key concepts) means we can grasp quickly the true impact of an adoption of a new capability would have, and what is needed to realize this in the environment as planned. Where I will focus is on the less obvious. This is the relationships across the other three domains (Business, Information, and Applications) which will be dependent on this enabling infrastructure. And no less important is the supporting organization ability to continue to deliver this capability when the “consultants” and vendors are long gone.
So if you look at the simple road map fragment illustrated below note the technology focus. Notice also what is missing or not fully developed. Although we have a bubble labeled “Build Organizational Capability” it is not specific and detailed enough to understand how important this weakness is to overcoming an improved product because of the technology focus.
Understanding of this one domain (technology) becomes a little trickier when take into account and couple something like an Enterprise Business Motivation Model for example . Now we can extend our simple sequence optimization with a very thoughtful understanding of all four architecture domains to truly understand what the organization is capable of supporting. So I’m going to reach into organizational dynamics now assuming all of us have a very good understanding as architects of what needs to be considered in the information, application, and supporting technology domains.
Organization Maturity Models
Before diving into the sequence optimization we should step back and review some of our earlier work. As part of understanding current and desired end states we developed a pretty acute awareness of the organization profile or collection of characteristics to describe ourselves. There are many maturity models available (CMMI,Information Management Maturity Model at Mike 2.0, and the NAS CIO EA Maturity Model) that all share the same concepts usually expressed in five or six levels or profiles ranging from initiating (sometimes referred to as chaos) to optimized. Why is this important? Each of these profiles includes any number of attributes or values that can be quantified to gain a deeper understanding of capability. This where the heuristic of common sense and intuitive judgment is needed and overlooked only at the risk of failure. For example, how many of us have been engaged in a SOA based adoption only to discover the technology is readily achievable but the organization’s ability to support widespread adoption to realize the value is not manageable or produces unintended consequences. Why does this happen so often? One of the key pieces of insight I can share with you is there seems to be a widespread assumption you can jump or hurdle one maturity profile to another by ensuring all prerequisite needs are adopted and in use. Here is a real world case to illustrate this thought.
Note there were thirteen key attributes evaluated as part of the global SOA adoption for this organization. What is so striking about this profile (this is not my subjective evaluation, this is based on the client’s data) is the relative maturity of Portfolio Management and integration mechanisms and the low maturity found in some core competencies related to architecture in general. Core competency in architecture is key building block to adopting SOA on the size and scale as planned. The real message here is this organization (at least in the primary architecture function) is still a Profile 1 or Initiating. Any attempt to jump to a Defined or even Managed profile cannot happen until ALL key characteristics are addressed and improved together. The needle only moves when the pre-requisites are met. Sounds simple enough, can’t count how often something this fundamental is overlooked or ignored.
Organization Profile
This is a little more sophisticated in its approach and complexity. In this case we are going to use a maturity model that attempts to clarify and uncover some of the organizational dynamics referred to earlier in our Gap Analysis. This model is based on the classic triangle with profiles ranging from Operational to Innovating (with a stop at Optimizing along the way). Each profile has some distinct characteristics or markers we should have recognized when base lining the Current State (if you used theGalbraith Star Model to collect you findings, its results can always be folded or grouped into this model as well). Within each of the profiles there a couple of dimensions that represent the key instrumentation to measure the characteristics and attributes of the organization’s operating model. This is useful to measure as the organization evolves from one Profile to another and begins to leverage the benefits of each improvement in reach and capability.
We use this to guide us to select the proper sequence. The dimensions used within each of the six profiles in this model include:
Infrastructure (Technology)
The computing platforms, software, networking tools, and technologies (naming services for example) used to create, manage, store, distribute and apply information. This is the Technology architecture domain I referred to earlier.
Processes
Policies, best practices, standards and governance that define: how information is generated, validated and used. How information is tied to performance metrics and reward systems. How the company supports its commitment to strategic use of information.
Human capital
The information skills of individuals within the organization and the quantifiable aspects of their:
-
capability,
-
recruitment,
-
training,
-
assessment and
-
alignment with enterprise goals.
Culture
Organizational and human influences on information flow — the moral, social and behavioral norms of corporate culture (as shown in the attitudes, beliefs and priorities of its members), as related to the use and value of information as a long-term strategic corporate asset.
What this reveals about our sequencing is vital to understanding key predecessor – successor relationships. For example, a Profile 1 (Initiating) organizations are usually successful due to visionary leaders, ambitious mavericks and plain good old-fashioned luck. Common characteristics include:
- Individual leaders or mavericks with authority over information usage
- Information infrastructure (technology and governance processes) that is nonexistent, limited, highly variable or subjective
- Individual methods of finding and analyzing information
- Individual results adopted as “corporate truth” without the necessary validation
Significant markers you can look for are usually found in the natural self-interests of individuals or “information mavericks” who will often leverage information to their own personal benefit. Individuals flourish at the expense of the organization. The silo orientation tends to reward individual or product-level success even as it cannibalizes other products or undermines enterprise profitability. Because success in this environment depends on individual heroics, there is little capability for repeating successful processes unless the key individuals remain the same. This dynamic never scales and in the worst cases the organization is impaired every time one of “these key employees” leaves taking their expertise with them.
By contrast a Profile 3 (Integrated) organization has acknowledged the strategic and competitive value of information. This organization has defined an information management culture (framework) to satisfy business objectives. Initiatives have been undertaken enhance the organization’s ability to create value for customers rather than catering to individuals, departments, and business units. Architecture integrates data from every corner of the enterprise — from operational/transactional systems, multiple databases in different formats and from multiple channels. The key is the ability to have multiple applications share common “metadata” — the information about how data is derived and managed. The result is a collaborative domain that links previously isolated specialists in statistics, finance, marketing and logistics and gives the whole community access to company-standard analytic routines, cleansed data and appropriate presentation interfaces. Common characteristics include:
- Cross-enterprise information.
- Decisions made in the context of enterprise goals.
- Enterprise information-governance process.
- Enterprise data frameworks.
- Information-management concepts applied and accepted.
- Institutional awareness of data quality.
So how well do think adopting an enterprise analytic environment is going to work in a Profile I (Initiating) organization? Do you think we have a higher probability of success if we know the organization is closer to a Profile III (Integrated) or higher?
I thought so.
In this case, the sequencing should reflect a focus on actions that will move and evolve the organization from a 1 (Initiating) to a 2 (Consolidated), eventually arriving at a 3 (Integrated) profile or higher.
Understanding the key characteristics and distinct markers found in the organization you are planning for at this stage will be a key success factor. We want to craft a thoughtful sequence of actions to address organization and process related gaps in a way to that is meaningful. Remember has much as we wish, any attempt to jump to a higher profile cannot happen until ALL key characteristics are addressed and improved together. So if we are embarking on a truly valuable program remember this fundamental. In almost every roadmap I have reviewed or evaluated by others not very many of them seek to understand this critical perspective. Not really sure why this is the case since an essential element of success to any initiative is ensuring specific actionable activities and management initiatives include:
- Building organizational capability,
- Driving organizational commitment, and
- The program will not exceed the organization’s capability to deliver.
Results
Now that we have gathered all the prioritized actions, profiled the organization’s ability to deliver, and have the right enabling technology decisions in the right order it’s time to group and arrange the findings. While the details should remain in your working papers there are a variety presentation approaches you can take here. I prefer to group the results into easy to understand categories and then present the high level projects together to the team as a whole. In this example (simplified and edited for confidentiality) I have gathered the findings into two visual diagrams illustrating the move from a Profile 1 (Operational) labeled Foundation Building, to a Profile II (Consolidated) labeled Build Out. I have also grouped the major dimensions (Infrastructure, Processes, Human Capital and Culture) into three categories labeled Process and Technology, and combined Human Capital and Culture into Organization to keep things simple.
First the Profile I diagram is illustrated below. Note we are “foundation building” or identifying the optimal sequence to build essential capability first.
The move to a Profile II (Consolidated) is illustrated below. In this stage we are now leveraging the foundation building from earlier actions to begin to leverage what is important and take advantage of the capability to be realized.
Note at this time there is no times scale used; only a relative size denoting an early estimate of the level of effort from the Gap Analysis findings. There is however a clear representation of the order of what actions should be taken in what order. With this information we are now ready to move to the next step to develop and publish the completed Road Map.
Enterprise Architecture Leaders' Interview Series - Q&A with Gil Long
http://www.microea.com/search/label/EA%20Interview
Enterprise Architecture Leaders' Interview Series - Q&A with Gil Long
I caught up with Gil Long who has served IBM as a Business Development Executive, Distinguished Engineer and CIO Office Chief Enterprise Architecture leader. As the Worldwide Enterprise Architecture Community Leader, he specialized in architecture governance, strategic architecture design and infrastructure transition planning. He was responsible for IBM's enterprise architecture strategy and planning service offerings, global enterprise architecture training programs, and functioned as a member of IBM's Architect Certification Board.
Gil has had direct management responsibility for large IT organizations and staffing, and substantial ongoing budget accountability. His multi-industry experience includes international banking, securities, education, retail, healthcare, insurance, utilities, manufacturing, semi-conductor, airlines, telecommunications and government.
Gil is a competitive aerobatics and commercial pilot.
In many years of your experience across hundreds of customers, what is the fundamental thing that organizations miss about Enterprise Architecture?
Understanding the value of EA is often an issue. The value is not only about reducing IT cost, but investing in innovative ways to improve the business. In my opinion, many companies do not understand what EA is!
EA needs the buy-in from upper management, but most upper managements think it is merely a technical or standards issue, and miss the point that it covers all aspects of business and technical structure and management. It is very important to have someone at the sponsorship level who understands what EA is and what value it brings.
In your experience what has been one of the most remarkable transformations enabled by Enterprise Architecture?
Obviously, I am intimately familiar with IBM's EA and how it has influenced multiple internal transformations. I shared with you the IBM Transformation Story. Great showcase!
I have seen many other transformations in the client world. One involved the consolidation of 90 companies (utilities) into a common footprint! Generally, the more complex the environment, the greater the benefit EA can deliver.
What do you think is one of the most underrated aspects of Enterprise Architecture?
The leadership role that an Enterprise Architect can provide to the organization.
For an aspiring Enterprise Architect, what are some key things she needs to start working on right now?
[-] Understand what EA is and what value it brings to the organization.
[-] Get EA training. You could start with understanding TOGAF, which is an internationally recognized standard for Enterprise Architecture.
[-] Get certified if you can, it could establish your credibility both within and outside your organization.
[-] Develop strong relationships with stakeholders that are impacted by EA. Its importance cannot be overstated. Involve them in the process.
[-] Understand your industry. Industries have their own context, business process models, histories, politics and challenges. Understanding your industry gives you an edge when working with partners across the company.
[-] Work on your communication skills. Always put yourself in the shoes of your audience. Communicate in a way that the listener will understand. Your message should be simple, concise and actionable, and answer the question, ‘What’s in it for me?’.
[-] An Enterprise Architect needs to stand up and speak, evangelize ideas, develop consensus, work across boundaries. Do not throw up your hands and quit, or be draconian and say if I don’t get what I want, the world will come to an end!
Do you think Enterprise Architecture has a brand issue?
Yes, the name itself implies it is a technical concept, rather than an overall business concept. The word “architecture” conjures an image of a guy with his head down, drawing a complex picture! The word “enterprise” can also be a bit vague. The enterprise represents the totality of the business; including business partners, customers and other stakeholders, and the infrastructure they use to accomplish their objectives.
However, a good Enterprise Architect will be able to explain EA to anyone in terms they can understand.
At the risk of drawing you into the "war of EA frameworks", how important is the EA framework brand to you?
IBM's EA Method and Framework are important to me, since IBM 'invented' EA in the 1980's and participated in the internationalization of EA via TOGAF involvement. All frameworks have something to offer, but they essentially are all true to the same basic EA concepts.
You should select one EA approach for your enterprise, and TOGAF, the international standard for EA, is generally accepted across all industries worldwide.
You have quite a collection of funny "ditties"! Which one is your favorite?
I have many favorites, but the “You are here!” picture always gets a laugh from architects :-)
How many countries have you traveled to, for business? Which one was the most unique?
Fifty three countries! I've had so many wonderful experiences in these countries. Each had its challenges and rewards. Istanbul (banking) was unique, as was China (telecom), as was Taiwan (semiconductor), and Hawaii (education) ... working from the top of a mountain overlooking Pearl Harbor. Also, Prague, with a mixture of former communist and democratic staff, and South Africa (banking). Although cultures can vary from place to place, I find that the Enterprise Architects are universally smart, enthusiastic and hungry for knowledge about EA.
I smile when I think about nap time on sleeping mats during lunch in China, and loud cell phone conversations going on during a serious lecture!! What is normal in some countries is unusual in others.
Had to ask this - tell us a little bit about your flying hobby and what are your flying plans for 2013?
Just got back from Sun-n-Fun in Lakeland, Florida (major fly-in with thousands of airplanes). Next stop is Oshkosh, Wisconsin, the largest fly-in in the US, and possibly the world.
I practice aerobatics every week and feel quite comfortable being upside down, like any good Enterprise Architect :-)
I hope you all enjoyed my interview with Gil Long. As usual, please keep your comments and feedback coming, I love to hear from you - whether you agree with me or not! Thank you for reading.
lunes, 29 de julio de 2013
ENABLE BUSINESS STRATEGY THROUGH TECHNOLOGY INNOVATION
How is it possible for a local company to defeat global giants like Pepsi, Coca-Cola, and Watsons in your market segment and establish market leadership for more than a decade? The answer is given by Nongfu Spring, a Chinese company in manufacturing and retail industries. In my recent report “Case Study: Technology Innovation Enables Nongfu Spring To Strengthen Market Leadership”, I analyzed the key factors behind their success, and provide related best practice from enterprise architecture perspective. These factors include
- Business strategy is enterprise architecture's top priority. EA pros often need to be involved in project-level IT activities to resolve issues and help IT teams put out fires. But it's much more important that architects have a vision, clearly understand the business strategy, and thoroughly consider the appropriate road map that will support it in order to be able to address the root causes of challenges.
- Agile infrastructure sets up the foundation for scalable business growth. Infrastructure scalability is the basis of business scalability. Infrastructure experts should consider not only the agility that virtualization and IaaS solutions will provide next-generation infrastructure, but also network-level load balancing among multiple telecom carriers. They should also refine the network topology for enterprise security.
- SOA and BPM unify information silos for business visibility. Well-designed service-oriented architecture helps application experts address business challenges. Infrastructure, application, and business services designed around tech and/or business requirements establish the enterprise app backbone, and a business process management solution will enable end-to-end business visibility for the organization.
- Integrated converged infrastructure is an effective solution for BI on big data. Business intelligence is the key to strategic decisions. Traditional solutions on the database and application layers will encounter critical challenges in the age of big data. Converged infrastructure such as HANA, integrated with cloud-enabled solutions like Hadoop, would be an effective way to provide composite business insights to business execs.
- Organize IT to effectively address a variety of business needs. Companies should thoroughly identify internal stakeholders and prioritize their business requirements, and then organize their IT arm to effectively support the business change. Clear responsibilities and standardized processes are essential not only essential for operational excellence, but also for IT executives to balance strategic, tactical, and operational requests.
If you still have the doubt in how to leverage related technology, please take a deep dive into the report and reference from their success; however if you have other insights on using technology to advance business objectives, you are mostly welcome to provide your comments to this blog post.
Enterprise IT Architect
Duties & Responsibilities:
- Collaborating with Architects, Project Managers, Business Stakeholders, and Technical Stakeholders to support the delivery of business systems
- Collaborating with senior level stakeholders to provide enterprise architecture according to existing Technical Roadmap
- Providing architectural guidance and solutions to support current and future business requirements and recommendations to business and technical stakeholders regarding Enterprise Architecture
- Evaluating and assessing adherence of systems to roadmap, recommending corrective action when required, and assisting project teams to adjust their solutions to provide greatest benefit
- Identifying technology trends and leveraging them to meet business needs
Must-have Requirements:
- TOGAF Certification
- Previous Experience as a Project Manager, Project Lead, or Senior Systems Analyst within a Financial Institution
- 5-7 years of applied hands-on experience with Enterprise Service Bus technologies within the technical landscape of banking and financial sector clients
- 3-5 years hands-on experience with MS SQL, C#, and developing TCP/IP based tools including low latency patterns to consume critical real-time services
- 2-5 years' experience in Configuration Management, SDLC, and Data Management
- Fluency in communicating the relationship between those systems with both technical and nontechnical stakeholders
- Deploying workflow and WCF services to AppFabric
Nice-To-Have Requirements:
- Previous Enterprise-Level Experience with the Microsoft Technology Stack
- ITIL Certification
Please address all email inquiries in .doc or .docx (MS WORD) format, along with your background & experience compared to the requirements of this opportunity quoting reference #124-48-MH2896 in the subject line of your email. CV's can be sent directly to: 124-48-MH2896@apply.maxhire.net
Business Architect - (Analysis, Process, Artifacts, TOGAF)
http://www.aplitrak.com/?adid=amVtbWEuNDQ3NDkudHdpQHNjcmVjLmFwbGl0cmFrLmNvbQ
Business Architect - (Analysis, Process, Artifacts, TOGAF)
My financial client is seeking a Business Architect to work from their London head office, responsible for the development and maintenance of the business architecture.
You will be responsible for the analysis and assessment of the business’s capability requirements, business services architecture, business process models and application portfolio demands to support the business’s stated strategic aims. Responsible for the documentation and maintenance of the associated business architecture artefacts. In addition you will be responsible for the Shape business propositions – Investigate business demands and problems, seeking effective business solutions through improvements in automated and non-automated components of new or changed processes.
You will have a minimum of 5 years experience as a Business Architect with previous business analyst exposure, as well as having previous banking, finance or payments experience. You will also have previous experience of developing and maintaining the business architect and have the ability to liaise with all technology areas across the business.
Business Architect - (Analysis, Process, Artifacts, TOGAF)
miércoles, 24 de julio de 2013
Articulating the Value of GRC
Date: Thursday, May 30, 2013
Time: 11 am Pacific | 2 pm Eastern
Duration: 1 hour
Enterprise IT Architecture
Enterprise architects work with stakeholders, both leadership and subject matter experts, to build a holistic view of the organization's strategy, processes, information, and information technology assets. The role of the enterprise architect is to take this knowledge and ensure that the business and IT are in alignment. A sound sense of business and technical strategy is required to envision the "right" architectural approach, given the business objectives of the organization. By embedding proper GRC check points within the organization's IT infrastructure, architects can reduce the organizations exposure to a wide array of risks, threats and vulnerabilities that have a direct impact on the performance of the enterprise.
http://www.metricstream.com/roles/Enterprise_IT_Architecture.html
martes, 23 de julio de 2013
CIO questions
Smarter Marketing: A new shared agenda for the CMO and CIO
http://www.internetevolution.com/webinar.asp?webinar_id=29904&webinar_promo=29588
Powerful partners: CMOs + CIOs = Front office transformation
Can CIO's afford to ignore Enterprise Architecture any more
Speaking the Language of Business with TOGAF®
http://enterprisearchitects.com/speaking_the_language_of_business_with_togaf/
I remember as a young child coming from a ‘non-sports obsessed’ family, I didn’t know what a yorker was, didn’t know what ‘LBW’ meant, or why Dennis Lillee or Geoffrey Boycott were such legends. I was ill equipped to join in on those all-important schoolboy conversations – the Monday morning autopsy of the weekend’s sporting events. Similarly, 30 years later, enterprise architecture presented me with the same dilemma.
I remember as a junior IT engineer, I’d hear the technology choice made by the customer was for ‘business reasons’, not what was logical in my technical view of the world. I now see ‘Architecture’ was influencing the project decisions, it was the source of the ‘business reasons’.
In my early days as an Architect, it was like being back at primary school; I struggled with the conversation. There was a level of assumed knowledge with respect to the conversation and the process that was not readily accessible to me. So, I learnt the long and hard way.
Fast forward a decade or so… As a mandatory requirement of my new role with Enterprise Architects I recently attended our TOGAF® training. To be honest, I anticipated another dry, idealistic framework that, whilst relevant to the work that I do, would probably not be all that practical and would be difficult to apply to a real world situation. How wrong was I?
Don’t misunderstand! The TOGAF® manual is dry! Yes it is “another framework” and yes you do need to tailor it to the situation you are in, but this is one of its greatest strengths, this is what makes it so flexible and therefore relevant and applicable to real world situations. But it’s not the framework itself that has me excited. It’s what it enables.
To me TOGAF®:
- Is a common language, linking the discovery from each of the domains together and to the business requirements, across different levels of the business in an iterative process.
- Provides a toolset to articulate the complex, simply.
- Provides a backstop, giving traceable, auditable decision support for those difficult conversations.
- Allows the development of focused visual models of complex and disparate sets of data.
This was clearly demonstrated to me on a recent engagement. I was deep in thought, staring at a collection of printed Architecture Models displayed on a wall. One of the admin staff with no IT or business background asked me what “it all meant”. I spent a few minutes explaining that these were models of the business and the technology used in it. Not only did they immediately understand the overall concept of what they were looking at, they were actually able to start extracting real insights from the models.
In my mind, it doesn’t get any better than that. I wish I had known about TOGAF® a decade ago, I would have been a better architect – and a lot sooner.
EA Matter. GODS and FFLV
http://www.enterprise-architecture-matters.co.uk/
GODS: Governance- Operations- Development-Support Enterprise reference model
FFLV: Functions-Flows-Layers-Views Enterprise Architecture Framework key patterns.
lunes, 22 de julio de 2013
IT Portfolio Management Using Enterprise Architecture and ITIL® Service Strategy
http://es.slideshare.net/ISS-NUS/portfolio-management-itil-ea
http://sergethorn.blogspot.com.es/2007/12/itil-v3-enterprise-architecture-and.html
http://www.packtpub.com/article/managing-it-portfolio-using-troux-enterprise-architecture
http://www.packtpub.com/article/managing-it-portfolio-using-troux-enterprise-architecture
domingo, 21 de julio de 2013
viernes, 19 de julio de 2013
miércoles, 17 de julio de 2013
martes, 16 de julio de 2013
lunes, 15 de julio de 2013
Enterprise Architecture done right drives Enterprise Transformation
EA , HP, TOGAF
Eric Sweden, Program Director, Enterprise Architecture & Governance, NASCIO will be delivering one of the keynotes in the Plenary Session of The Open Group Conference in Philadelphia. I read the abstract for his keynote with great interest. Sweden asserts “Enterprise Architecture” provides an operating discipline for creating, operating, continual re-evaluation and transformation of an “Enterprise.” Not only do I agree with this assertion, but I would add that the proper creation, operation and continuous evaluation of the “Enterprise” systemically drives its transformation. Let’s see how.
Creation. This phase involves the definition of the Enterprise Architecture (EA) in the first place. Most often, this involves the definition of an architecture that factors in what is in place today while taking into account the future direction.TOGAF (The Open Group Architecture Framework) provides a framework for developing this architecture from a business, application, data, infrastructure and technology standpoint; in alignment with the overall Architecture Vision with associated architectural governance.
Operation. EA is not a done deal once it has been defined. It is vital that the EA defined is sustained on a consistent basiswith the advent of new projects, new initiatives, new technologies, and new paradigms in alignment with the New Style of IT. As the abstract states, EA is a comprehensive business discipline that drives business and IT investments. In addition to driving investments, the operation phase also includes making the requisite changes to the EA as a result of these investments.
Continuous Evaluation. We live in a landscape of continuous change with innovative solutions and technologiesconstantly emerging. Moreover, the business objectives of the enterprise are constantly impacted by market dynamics, mergers and acquisitions. Therefore, the EA defined and in operation must be continuously evaluated against the architectural principles, while exercising architectural governance across the enterprise.
Transformation. EA is an operating discipline for the transformation of an enterprise. Enterprise Transformation is not a destination — it is a journey that needs to be managed — as characterized by Twentieth Century Fox CIO, John Herbert. To Forrester Analyst Phil Murphy, Transformation is like the Little Engine That Could — focusing on the business functions that matter. (Another keynote at this conference is on the impact of Big Data on Enterprises — a paradigm gaining a lot of ground for enterprises to stay competitive in the future.)
Global organizations are enterprises of enterprises, undergoing transformation faced with the challenges of systemic architectural governance. NASCIO has valuable insight into the challenges faced by the 50 “enterprises” represented by each of the United States. Challenges that contrast the need for healthy co-existence of these states with the desire to retain a degree of autonomy. Therefore, I look forward to this keynote to see how EA done right can drive the transformation of the Enterprise.
viernes, 12 de julio de 2013
jueves, 11 de julio de 2013
lunes, 8 de julio de 2013
domingo, 7 de julio de 2013
viernes, 5 de julio de 2013
jueves, 4 de julio de 2013
miércoles, 3 de julio de 2013
martes, 2 de julio de 2013
Checking the SCORE
http://weblog.tetradian.com/2013/06/29/checking-the-score/?utm_source=dlvr.it&utm_medium=twitter
My answer? Check out the SCORE: Strengths, Challenges, Options, Responses, Effectiveness.
WhatFirst Software
Accelare Announces WhatFirst 2013
I am excited about the new edition of our business architecture product, WhatFirst™. Here is the scoop.
Accelare announces the general availability of WhatFirst™ 2013, the next generation of Strategy-to-Execution software on the Microsoft SharePoint 2013 platform. WhatFirst™ is designed as a planning tool to unpack strategy into executable packages of integrated work and provide organizations with an explicit approach for turning strategy into a set of properly designed sequenced and adequately resourced actions to deliver predictable and measureable results. With WhatFirst™, organizations reduce the risk of project failure, the impact of destructive and unorganized multi-tasking, and increase the velocity of strategy execution while running the current business.
WhatFirst™ comes with five integrated modules to manage the Strategy-to-Execution and Business Architecture disciplines of the firm.
- The Strategy Module helps firms to define their strategic differentiation from different constituent points-of-view and document and cascade strategies, goals, and objectives across the organization.
- The Capability Module helps firms identify and prioritize critical capability gaps to achieve strategic intent.
- The Resource Model helps companies link and manage people, technology, information and other resources required to execute on the strategic agenda.
- The Planning Module supports the development of an investment roadmap for the business directly linked to the strategies, capabilities, and resources of the firm and its suppliers.
- The Execution Module is used to create metrics and scorecards to manage strategy execution on a day-to-day basis.
As a SharePoint 2013 application offering available in either SaaS or on-premise form, WhatFirst™ extends SharePoint’s native functionality as a collaborative platform to more broadly engage managers and employees in the strategic thinking and execution planning efforts of the firm. Users can appropriately create, review, contribute to, and collaborate on the development of strategy or plans for execution. SharePoint lists and documents can be easily linked to any component of the WhatFirst™ application.
The bottom line:_______________________________________________________________________________________________
WhatFirst™ is a powerful tool for business architects interested in capability management. You can go here to learn more and request a demo.
lunes, 1 de julio de 2013
How to Have the IT Risk Conversation
http://blogs.hbr.org/cs/2013/06/how_to_have_the_it_risk_conver.html
I run a course at the MIT Sloan School called Essential IT for Non-IT Executives. Every time my colleagues and I come to the end of the course, we ask people what they considered the most important thing they learned. Surprisingly, many people say it was "how to have the IT risk conversation."
As one CFO told me, the phrase "IT Risk" contains two dirty words. The word risk makes him feel uncomfortable. And the word IT makes him feel incompetent. Not a good way to feel ready for a productive dialogue. But being able to talk about IT risk is essential if you are going to make the right decisions about how you use technology in your business.
Fortunately, there is a way to talk about IT risk — and understand risk — in terms that make sense to every manager. If you can remember four A's, you have the framing for a productive conversation with your IT counterparts. You can come to common understanding about what IT risks are most important, what causes them, and what you'll do about them.
From a business standpoint, IT risks affect four key objectives:
- Availability: Keeping business processes running, and recovering from failures within acceptable timeframes
- Access: Providing information to the right people while keeping it away from the wrong people
- Accuracy: Ensuring information is correct, timely, and complete
- Agility: Changing business processes with acceptable cost and speed
If you're like managers in most companies, you tend to have conversations about these four A's in silos, if at all. You never talk about all four together. That means experts in each risk silo tend to focus on optimizing their own risks, not optimizing across risks.
For example, ask yourself: do your security people think about agility risks? When security people veto your requests, they really mean that you're introducing unacceptable or unnecessary risks. But their veto can slow or stop the changes you need. If you don't talk about all four risks, then how do you know what risks are really acceptable?
In the best companies, security people think about all four A's. They consider agility as well as access risks. They will suggest ways that you can do what you want more safely. They'll even work with other silos — IT operations, application development, compliance, legal, HR, etc. — so they're ready for you when you want to do new things.
When your security people focus on all four A's, you can move quickly to adopt new mobile devices, launch digital businesses, or exploit social media. But unfortunately, too many security people focus only on the risks that matter to them. In protecting against access failures, they fail to help the company move forward.
Getting Started on the Risk Conversation
When you don't explicitly talk about the four A's, people make assumptions about what's most important. Those assumptions will vary from person to person. Conversely, when you talk openly about the four A's, you can fix false assumptions, and you can make better decisions. But you have to start the conversation.
Try the following exercise: Find your favorite IT person. Tell him how important each of the four risks is for your part of the business. Tell him how you think he's doing at managing those risks. Then listen. I guarantee that you'll both learn something.
If your experience is typical, you'll find that you and your IT people place different importance on the four A's. For example, in a global survey of 258 executives, IT and business executives agree on the relative importance of availability and access risks. But business execs put far more importance on agility and accuracy risks than IT execs do.
What's going on? Why don't IT people share your love of accuracy and agility? It's easy to think it's an incentive problem. IT people get the blame when systems go down or hackers succeed. But when projects move too slowly or you don't have a unified view of your customers, you may feel more pain than them. But this incentive answer is only partially correct, if at all.
The real cause of this misalignment lies much deeper; a legacy of risk-unaware decisions and poor communication across silos. Improving agility and accuracy typically requires cleaning up a spaghetti-like mess of systems and processes built up over decades. They can't be fixed just by buying a new device or devising a new procedure. When your IT people seem to value agility and accuracy less than you, they may have simply given up hope of fixing them. The solution may lie beyond their sphere of influence. Or they may be so busy keeping things running that greater agility feels like a pipe dream.
This is where communication matters. You can only fix the legacy problem by jointly understanding the risks that matter now, the risk tradeoffs in each decision, and the actions required to resolve your risks. Discussing IT risk does more than help you make better project decisions. It also helps you understand when it's time to rework some of the mess your organization has accumulated over the years.
So, make IT risk part of your conversations every day. Discuss the four A's whenever you make a big IT decision. If your security people talk only about security, they're missing important risks — and useful opportunities. But when you ask for unnecessary exceptions, or ask your IT people to move too fast, you're inappropriately favoring agility over the other three risks— and setting yourself up for trouble later.
One thing is sure. If you don't talk about IT risk, you only make your risks worse. How do youmanage your IT risk conversations?
Suscribirse a:
Entradas (Atom)