http://www.projecttimes.com/kiron-bondale/be-a-mindful-project-manager.html
miércoles, 29 de abril de 2015
EA Links
Enterprise adaptation to technology change is key to survival
http://www.ebizq.net/blogs/ea_matters/2014/06/is-architecture-about-technology.php
Do we need an Enterprise Architecture Theory? We do.
http://it.toolbox.com/blogs/ea-matters/do-we-need-an-ea-theory-we-do-66356
Does Enterprise Architecture really enable the enterprise transformation?
MEGA named leader by Forrester for Strategic Planning for the BT agenda
MEGA named leader by Forrester for Strategic Planning for the BT agenda
jueves, 23 de abril de 2015
lunes, 20 de abril de 2015
Enterprise Architecture Concepts
https://www.linkedin.com/pulse/20140622135614-86002769-enterprise-architecture-concepts
Enterprise architecture is widely misunderstood, and there is a deficit of trained and educated architects that can conceive of the full scope. There are several basic concepts you should be aware of in understanding enterprise architecture. Different schools of thought treat these differently, some including this and excluding that as adjacent, but they are each part of that picture. These concepts include:
- Strategic Planning
- Implementation
- Architecture
- Vision
- Alignment
- Transformation
- Strategic Advantage
- Technology
- Line of Business
- Frameworks
- Artifacts
- Business Processes
- Levels
- Areas
- Governance
- IT Investment
- Return on Investment
- Performance
- Portfolio
- Systems
- Lifecycle
- Integration
If your enterprise architects do not see the full picture and do not understand these basic concepts, you are not getting the full value of enterprise architecture. If you are an enterprise architect and do not see the full picture or do not comprehend how these basic concepts relate to your practice, you are not delivering the full value to the customer. As training, education and certification improve the full picture should, over time, become better understood.
Strategic Planning
Enterprise architecture is closely associated with strategic planning or IT strategic planning. Some view enterprise architecture as planning. A common main output of the enterprise architecture activity is a transition plan (aka roadmap or transformation plan).
Examples:
Steven H. Spewak’s book “Enterprise Architecture Planning, Developing a Blueprint for Data, Applications and Technology” ISBN 0-471-59985
Another book: Jeanne W. Ross et. al. “Enterprise Architecture as Strategy: Creating a Foundation for Business Execution” ISBN 1-59139-839-8
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.
The top policy for enterprise architecture of the U.S. Federal Government, OMB Circular A-130, transmittal 4, identified strategic planning as a direct input to enterprise architecture.
Implementation
Implementation of something is why you do an architecture. If you are implementing nothing there is little need to do an architecture. Without implementation the ROI (retun on Investment) for architecture is quite restricted, consisting of cost savings for what you did not implement.
Examples:
John A. Zachman: “During the 1980′s, I became convinced that architecture, whatever that was, was the thing that bridged strategy and implementation”.
Architecture
Atchitecture is about designing something to be constructed. It is a primarily visual practice communicated through drawings and specifications.
Definitions of ARCHITECTURE (ar·chi·tec·ture \ˈär-kə-ˌtek-chər\)
Merriam Webster: 2a : formation or construction resulting from or as if from a conscious act architecture of the garden> b : a unifying or coherent form or structure architecture>… 5 : the manner in which the components of a computer or computer system are organized and integrated
Dictionary.Com: 1: the profession of designing buildings, open areas,communities, and other artificial constructions and environments, usually with some regard to aesthetic effect.Architecture often includes design or selection of furnishings and decorations, supervision of construction work, and the examination, restoration, or remodeling of existing buildings.
Vision
Architecture is commonly considered to be a visual process. In architecture it is common to produce a “vision” or picture of the future state. Enterprise architecture also commonly produces a vision of the future (aka target or to-be) state. It is this vision which is commonly used to convince stakeholders to buy in to the direction and process of the architecture.
Examples:
- In the TOGAF framework there is a phase named “vision”.
- In the FEAF one output is a vision.
- In the DODAF the OV-1 CONOPS diagram provides a visual depiction of the future state, essentialy a vision.
Alignment
Alignment in enterprise architecture is when all the efforts “line up” to support the organizational strategy, or when lower level detail supports higher level architecture. When all the artifacts agree, you have “alignment”. Alignment is often checked by governance.
Examples:
One FEAF artifact, the “line of sight diagram” is a depiction of the project linked through improved performance measures to business outcomes and the organizational strategic goals.
Transformation
Transformation (aka business transformation or transformation of government) is the concept of changing the organization and its processes or structures to improve performance. Enterprise architecture is about transformation, expressing a current state a target state and a transition plan.
Strategic Advantage (Differentiators, Capabilities)
When a strategic goal or goals (aka “mission needs”) are supported by an executable implementation the result is a “strategic advantage”. A “strategic advantage” may also be called a differentiator (commercial use) or a “capability” (mainly government use). Enterprise architecture is commonly and routinely associated with the production of these “capabillities” or “differentiators” that constitute a “strategic advantage”. Many are unaware of this linkage because of disparate terminology, but one common definition of enterprise architecture is “the link between strategy and execution” which is again roughly synonamous. Michael Porter called this Competiitive Advantage.
Examples:
- TOGAF 9 includes a section of capabilities based planning
- DODAF is tightly associated with JCIDS (Joint Capabillities Integration and Development System).
- DODAF 2.0 includes a capabilities metamodel.
- Zachman International provides seminars for using EA to produce business advantage.
Technology
Definition of Technology (tech·nol·o·gy [tek-nol-uh-jee] noun):
… 4. the sum of the ways in which social groups providethemselves with the material objects of their civilization. (dictionary.com)
As the term is used here, technology is th basis of all strategic advantage, differentiators or capabilities. Initially EA was associated with only information technology, but wider applicability has since occurred.
Example:
In 1983 a classified program was initiated in the US intelligence community to reverse the US declining economic and military competitiveness. The program, Project Socrates, used all source intelligence to review competitiveness worldwide for all forms of competition to determine the source of the US decline. What Project Socrates determined was that technology exploitation is the foundation of all competitive advantage and that the source of the US declining competitiveness was the fact that decision-making through the US both in the private and public sectors had switched from decision making that was based on technology exploitation (i.e., technology-based planning) to decision making that was based on money exploitation (i.e., economic-based planning) at the end of World War II.
Technology is properly defined as any application of science to accomplish a function. The science can be leading edge or well established and the function can have high visibility or be significantly more mundane but it is all technology, and its exploitation is the foundation of all competitive advantage.Technology-based planning is what was used to build the US industrial giants before WWII (e.g., Dow, DuPont, GM) and it what was used to transform the US into a superpower. It was not economic-based planning.
Project Socrates determined that to rebuild US competitiveness, decision making throughout the US had to readopt technology-based planning. Project Socrates also determined that countries like China and India had continued executing technology-based (while the US took its detour into economic-based) planning, and as a result had considerable advanced the process and were using it to build themselves into superpowers. To rebuild US competitiveness the US decision-makers needed adopt a form of technology-based planning that was far more advanced than that used by China and India.
Line of Business aka Value Chain or Value Stream
A “line of business” is a particular product line. The term is also applied in EA to any functional area, including human capital, financial management, or logistics. A “line of business” is often the basis of an architecture inside the enterprise, and corresponds to the terminology “segment” used in Burk’s levels. Another term of similar use if “domain” as in “domain architecture”. A “line of business” may be a mission area or profit center, or it may be a support function or cost center. In EA the idea is to give priority to those areas that are important to the mission or produce profit.
In enterprise architecture the “line of business” or segment or domain is the level at which most business process reengineering, value chain analysis, supply chain analysis, operational analysis etc. occurs. An example of this is the Federal Segment Architecture Methodology. Another example is the Business Transformation Architecture (BTA) effort at DoD.
Frameworks
In enterprise architecture the “framework” holds a special role. In my opinion this is because enterprise architecture practice began with competing vendors in system integration, not in academia. Each participating company produced some competing conceptual model, and later this practice was adopted by government to conceptualize various parts of the practice. There are different types of frameworks, applicable to different levels and layers and mechanisms in the scope of enterprise architecture:
- Frameworks for solution architecture (DODAF, TOGAF)
- Frameworks for enterprise level architecture (ZIF, FEAF)
- Frameworks for segment (Line of Business) architecture (FSAM, DODAF tailored)
- Frameworks for enterprise architecture maturity (EAMMF)
- Frameworks for sequence, such as an SDLC (INCOSE SDLC, IEEE SDLC, DoD SDLC, DHS SELC)
- Frameworks for data or information architecture (Martin’s Information Engineering, Oracle Case Method tm)
- Frameworks for business architecture (Hammer’s BPR…)
- Frameworks for software architecture (Booch, SEI, UML)
- Frameworks for standards and infrastructure (COBIT)
- Frameworks for shared services (ITIL)
(Some believe in the ultimate “uber-framework”, a mythical super-method like the “theory of everything” in physics. Personaly, I do not think frameworks should be expanded from their focus, where they are excellent, into areas of mediocrity. For the moment we must use multiple frameworks, or parts of several. I suggest picking a minimum set and using them with improving maturity. Standard, public frameworks are superior to proprietary frameworks for which one must pay: Avoid being held hostage by vendors of frameworks with recurring fees or mandatory services.)
Artifacts
Artifacts come in various types:
Architecture & Engineering Drawings
Spreadsheets
Documents
Artifacts are the concrete output (deliverables) of an enterprise architecture effort. Sometimes these may be embodied in data inside a tool so you can create new artifacts on the fly. Artifacts (and the facts or plans they represent) are reviewed and approved via governance.
Business Processes
Enterprise architecture is the fusion of business and technology. This is accomplished in large part through business processes analysis and reengineering or continuous process improvement, the very same techniques used in human resources, operations management, logistics and supply chain management, Six Sigma, and TQM.
The US Government defines enterprise architecture in OMB Circular A-130: “What is the Enterprise Architecture? (a) An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology.”
DODAF and derivatives include business process diagrams, and in DODAF these are labled “OV-5″ or operational view number five.
TOGAF identifies “Phase B” as business architecture, including business process analysis.
Levels
Levels in Enterprise Architecture
In 2006 Dick Burk, Chief Architect at OMB at the time, identified that enterprise architecture has different levels. This important conflict deconflicted endless arguments between architects at the tactical (solution) level and the strategic (enterprise) level. With the concept of levels in enterprise architecture practice it is now possible to see that there are three different kinds of activity with different scope possibly performed by three different teams (or more). Without this concept your EA efforts may become tactical and without strategic impact, or strategic but without concrete results.
Layers (aka Columns, Areas)
The concept of layers should not be confused with Burk’s concept of levels of enterprise architecture. In the NIST model five layers were identified (business, information, application, data, infrastructure), and these were modified for the FEAF framework as four levels (business, data, application, technology). Both are related to Zachman’s columns (all three images are from the FEAF where this is discussed). One could make a case that thiese layers relate to DODAF views as well. The concept of “layers” implies a flow from one to another, a precedence or order, as descrivet in NIST. Each of these layers consitiutes a different area or specialization in architecture and often a different member of the enterprise architecture team.
Governance
In enterprise architecture governance is used in the sense of corporate IT compliance, in the sense of Sarbanes-Oxley or Basil II. IT systems must comply with various laws, policies, plans, standards and higher level architecture. Enterprise architecture artifacts and system engineering plans are reviewed by governance processes. Those processes vary by organization.
Conversely actual systems are checked for compliance via testing.
IT (Information Technology) Investment
For several years now information technology has been managed as an investment. It is seen not as a cost of doing business, but as a means to improve operations. Information technology and IT systems have become massively expensive in large corporations and especially the U.S. Federal Government, and just buying some software because it seems useful is no longer justifiable. Each IT purchase is now managed as a means to effect organizational change, a way to make the organization perform. The cost is compared not to the system features and functions, but to the improvement in organizational operations and the decreased operations cost or increased revenue that will result.
This approach can be applied to any technology purchase, not just IT.
Return on Investment
The purchase of more information technology is treated as an investment. To justify the investment there must be a return on that investment, payback.
The return on any investment, including an IT investment, you list the tangible and intangible costs versus the tangible and intangible benefits. A document containing this information and making any ROI calculations is often called a Cost Benefit Analysis.
The benefits to the procuring organization are not system features but improved organizational operations. In the U.S. Federal Government more benefits are intangible, because it is politically infeasible to measure the dollar value of human suffering, starvation, death, or other things that may be affected by government operations.
Performance
Enterprise architecture improves organizational performance using technology, by leveraging technology investment. Organizational performance is made tangible by the use of performance measures. Performance measures may relate to money (cost, price), quality or timliness (throughput, volume). Any product or service or entire company can be measured in these categories.
Any business process can be measured and improved. These improvements also fall in the three basic categories of money (cost, price), quality or timeliness (throughput, volume). When you automate or streamline some business process these measures change. Such a change in performance constitutes the return on investment of the automation.
A measurable change in measured performance indicators is sometimes called a “business outcome”. When a new capability is operationally implemented you get a business outcome.
Portfolio
How do you decide which technology improvements to make in your organization, and which to cancel? If technology and IT procurement is treated as an investment, then you treat the question as a portfolio of investment. You perform portfolio management.
A portfolio of investment lists each investment, its cost, its level of return (return on investment), and its risk. You put the investment with the highest ROI at the top. Eliminate all the poor investments. Working from the top down, you draw a red line when you run out of budget for these investments. The investments above the line are what you fund, and those below are what you cancel.
As your investment proceeds you monitor that it performs as predicted. If the return drops or the risk spikes you review the investment for cancellation.
Systems (Theory & Engineering)
For some time the western world believed that if you could list every part of a thing, you understood that thing. Ludwig Von Bertanalfy changed that with general system theory. In GST things have interactions and you need to understand that. They have interfaces. Interactions may follow patterns, like strange attractors or cycles ammenable to Fourier analysis, or they may have cybernetic feedback.
Some such systems with many interactions may be complex. If you build a complex system you may need means to control and specify so many parts that no one person can grasp the whole thing. You may need system engineering. It has means to manage complexity.
Systems may be defined, like boxes. You may treat the internals as unknown and just specify the interfaces, black boxes. You may see inside and treat them as white boxes.
The enterprise is a system. Each IT investment is a system. Integrated sets of IT are systems. EA is meaningless without the concepts related to systems.
Lifecycle
Systems have a lifecycle. Typicaly there is a systemm development lyfecycle (provided by systems engineering) with stage-gates to mark major phases and transitions. The system is concieved, planned, developed, tested, operated and later disposed of. One system replaces another. All this takes time, and planning. Without that one system will break down as unsupporable and you may be in a huge rush to replace it with anything, perhaps not the best replacement, and you may be willing to spend extra to do it. The results of planning are reflected in the enterprise transition plan.
Investments also have a lifecycle, with reviews. These mark the ROI and the breakeven points, and should also be reflected in the transition plan.
Integration
Enterprise Architecture is a term initially coined within the context of addressing problems of system integration. To share information and support business processes from end to end it is typical to integrate systems together. Some years ago Manufacturing Resource Planning susye,ms were connected to accounting systems and ERP resulted, for example. There is still a strong need to connect systems together, via SOA, EAI, ESB or other means.
When you take items vended as a system, like ERP, and connect them to other systems you get a system of systems.
Business Architecture the Glue Between Business Strategies and IT
http://community.biz-architect.com/about-ba/business-architecture-glue-business-strategies/
Business Architecture in the Enterprise Design Space
https://www.linkedin.com/pulse/business-architecture-enterprise-design-space-daniel-lambert
domingo, 19 de abril de 2015
Atychiphobia – The Enemy of Innovation
Why are many companies reluctant to embrace IT innovation?
http://www.regent.edu/acad/global/publications/jsl/vol3iss2/JSL_V3Is2_Kuyatt_pp31-40.pdf
jueves, 16 de abril de 2015
lunes, 13 de abril de 2015
Enterprise Transformation Office
https://www.linkedin.com/pulse/eapmo-matthew-kern
A PMO or Project Management Office is an element of the enterprise that maintains project management standards. Enterprise Architecture plans and monitors enterprise transformation. The two may be (and have sometimes been) combined in an EAPMO.
Other approaches to enterprise transformation or improvement fall far short of the breadth of vision and potential gains of agility, efficiency and effectiveness offered by the EAPMO organized to combine oversight of all transformative projects. I suggest the term Enterprise Transformation Office or ETO for this kind of organization.
PMO: The project management office (1,2) commonly maintains standards for project management, program management and portfolio management. It is a single unique operation within the enterprise. As the enterprise should have only one portfolio to avoid suboptimization, there is discussion as to if the PMO should perform the portfolio management for the organization.
EA: Enterprise Architecture, as described in FEA and FEAF, is decision support for organizational portfolio management. It is closely connected to portfolio management in its main or top-level process. (3,4,5,6,7,8,9, 10) EA and portfolio management should be organizationally close, tied together, to achieve gains through transformation.
Transformation: Transformation changes the enterprise, improving operations or creating new capabilities. The primary means of causing this transformation is the project, possibly organized into programs, and managed by the portfolio. This is differentiated from functional or operational management which oversees steady-state operations in the enterprise. The primary purpose of the PMO is to achieve organizational transformation. (11,12,13,14, 15, 16) Again, organizational proximity would help.
Portfolio Management: There are strong reasons to integrate, or tightly relate the portfolio management function with its enterprise architecture decision support. These are intended to operate in a tight cycle. If you also agree that the PMO should perform the organizational portfolio management, then there is significant potential synergy in combining the PMO, EA and portfolio management in a single organizational unit. (17,18)
Such an organization would contain experts in the distinct disciplines of EA, project management and portfolio management, presumably in distinct sub-units, located together for organizational efficiency. It would possibly be headed by the person responsible for organizational transformation.
When these functions are not combined significant synergy, efficiency and effectiveness can be lost.
(In the US Federal Government portfolio management is called CPIC. The relationship between EA and portfolio management is described in OMB Circular A-130, and this relationship is the policy of the US Federal Government. Program and project review is also describe there as the "control" and "evaluate" phases of CPIC. Compliance with law and policy requires that these be treated together for all IT. Best practice would have these functions combined for non-IT as well, all transformational efforts of any kind.)
Roadmap: A roadmap is a schedule for transformation efforts. The enterprise transformational roadmap is a central artifact for both a PMO and EA. (19) Combining would again improve effectiveness.
Waste: Placing EA in the PMO can reduce waste. (20,21)
Governance: Unifying EA and PMO governance can save effort. (22,23)
Standards: The PMO promotes and possibly audits for standards applied to projects and programs. EA is intended to be the standards clearinghouse for the organization in various frameworks. This function can and should be unified. (24)
SDLC: The system lifecycle is a standard that should be managed and enforced by EA and PMO efforts, together. (25)
Vision: A key product of EA is the vision of the target (to-be) enterprise. This is what the programs and projects are attempting to create. There is bennefit in having that function performed in the PMO. (26)
EA Principles: Principles describe how projects and programs will perform transformation. There is benefit in having the PMO select and promote EA principles. (27)
Strategy: EA seeks to create a portfolio that implements the strategic plan. The PMO also seeks to create and management the portfolio of projects and programs to implement the strategic plan. There is benefit in unifying or centralizing these functions. (28, 29, 30)
Business and Technical Drivers: EA tracks the forces that drive organizational change, attempting to accommodate, leverage and even anticipate these forces. It is advantageous to merge this function into the PMO. (31)
Innovation: An ETO style EAPMO can reduce barriers to innovation and improve agility. (32)
Acquisition or Procurement: Each project or program must select implementation methods for its bit of organizational transformation. Some efforts may be outsourced. Some may be purchased. Some may be developed within the organization. Many require purchase of supporting software or other elements. With an ETO/ EAPMO acquisition or procurement is tactical support for the strategic efforts of the ETO, applied to the project or program. In effect, the ETO implements "strategic acquisition" or replaces any notion of or independent implementation of "strategic acquisition". However the ETOhas greater potential to do so in an effective and compliant way vice modern current organizational standards. (33)
Audits and IV&V: The ETOis the proper place to sponsor or conduct audits and IV&V (Independent Verification and Validation) Efforts, in addition to program or project reviews and progress reporting. (34)
Conclusion: If you perform portfolio management, enterprise architecture and management oversight of programs and projects then you should probably combine these functions into an ETO style EAPMO. There is significant overlap of function, and significant synergy to be achieved.
References:
-
https://www.linkedin.com/pulse/article/parsimony-vs-comprehensive-ea-matthew/edit
-
https://www.linkedin.com/pulse/article/20141129174141-86002769-ea-is-interdisciplinary/edit
-
https://www.linkedin.com/pulse/article/20141004183219-86002769-choose-five-frameworks/edit
-
https://www.linkedin.com/pulse/article/20140816204807-86002769-enterprise-architecture-purpose/edit
-
https://www.linkedin.com/pulse/article/20140816144513-86002769-enterprise-architecture-scope/edit
-
https://www.linkedin.com/pulse/article/20140622135614-86002769-enterprise-architecture-concepts/edit
- https://www.linkedin.com/pulse/article/20140622135425-86002769-enterprise-architecture-origins/edit
-
https://www.linkedin.com/pulse/article/enterprise-transformation-matthew-kern/edit
-
https://www.linkedin.com/pulse/article/integration-system-engineering-enterprise-matthew/edit
-
https://www.linkedin.com/pulse/article/20140920150603-86002769-where-to-start/edit
-
https://www.linkedin.com/pulse/article/20140803161040-86002769-the-value-of-enterprise-software/edit
-
https://www.linkedin.com/pulse/article/enterprise-architecture-portfolio-management-matthew/edit
-
https://www.linkedin.com/pulse/article/20140826222008-86002769-what-is-suboptimization/edit
- https://www.linkedin.com/pulse/article/20140920032120-86002769-enterprise-architecture-roadmap/edit
-
https://www.linkedin.com/pulse/article/20140802151937-86002769-change-without-purpose/edit
-
https://www.linkedin.com/pulse/article/20140921200744-86002769-10-ways-to-botch-ea/edit
- https://www.linkedin.com/pulse/article/20140921131156-86002769-approved-technologies-standards/edit
- https://www.linkedin.com/pulse/article/20141127015951-86002769-system-engineering-inefficiency/edit
- https://www.linkedin.com/pulse/article/20140912112037-86002769-enterprise-architecture-vision/edit
- https://www.linkedin.com/pulse/article/20140921154042-86002769-enterprise-architecture-principles/edit
-
https://www.linkedin.com/pulse/article/20140919090447-86002769-outcomes-vs-capabilities/edit
-
https://www.linkedin.com/pulse/article/20140822173711-86002769-culture-vs-strategy/edit
- https://www.linkedin.com/pulse/article/20140912125408-86002769-enterprise-architecture-drivers/edit
- https://www.linkedin.com/pulse/article/20140830141415-86002769-innovation/edit
- https://www.linkedin.com/pulse/article/20140704182755-86002769-cots-gots-vs-mots-vs-custom-developemnt/edit
- https://www.linkedin.com/pulse/article/20140726190101-86002769-performance-measures-in-the-enterprise/edit
Business Architecture Guild Announces the Certified Business Architect (CBA)® Program
Business Architecture Guild Announces the Certified Business Architect (CBA)® Program
- Home
- About BA
- Practitioners
- Finance
- Government
- Healthcare
- Manufacturing
- Retail
- Media
- Telecom
- Transportation
- Business Architecture Guild Announces the Certified Business Architect (CBA)® Program
Business Architecture Guild Announces the Certified Business Architect (CBA)® Program
Soquel, CA, February 07, 2015 –(PR.com)– The Business Architecture Guild is pleased to announce the Certified Business Architect (CBA)® program. This certification program reflects a major step forward for the rapidly expanding business architecture discipline. Business architecture certification enables organizations to more effectively define job descriptions, assess job candidates, review employee performance and structure programs that allow practitioners to enhance their knowledge and skills. Certification also furthers the advancement and formalization of the business architecture discipline and profession.
The certification exam will consist of approximately 150 questions drawn from industry literature, the Guild’s BIZBOK® Guide and practical application scenarios. It will measure practitioner knowledge and experience in relevant topic areas. An individual who has passed the certification exam will be designated a Certified Business Architect™ and be able to display the CBA™ designation on their credentials.
The certification exam was established through a rigorous process that involved industry experts, practitioner peer reviews, psychometric analysis and formal beta testing. Examination content will include questions drawn from the following topic categories:
1. Business Architecture Foundational Concepts
2. Business Architecture Core Mapping Knowledge
3. Business Architecture Extended Mapping Knowledge
4. Business Architecture Alignment with Related Business Disciplines
5. Business Architecture & Business Performance Analysis
6. Business Architect Role
7. Business Architecture Governance
8. Business Architecture & IT Architecture Alignment
9. Business Architecture Situation & Scenario Usage
10. Business Architecture Infrastructure Management
Guild members have been very interested in this next evolutionary step in the maturation of business architecture. According to Timothy Gallivan of Washington State, “It is exciting to see that the Business Architecture Guild is bringing professional certification to the field of business architecture. Having business architects certified by the Guild gives us the confidence that those individuals will be equipped with a comprehensive set of skills and perform to the highest degree of standards.”
Certification is granted for a three-year period, with renewals offered for certification holders who earn Continuing Education Units (CEU) credits. CEU credits will be managed through the Business Architecture Guild. This will allow Certified Business Architect™ holders to maintain their certification designation, while ensuring that their skills are kept up to date.
The certification exam will be taken in person and proctored by Pearson VUE at any one of their thousands of testing locations worldwide. To enable worldwide access to the Certified Business Architect (CBA)® exam at Pearson VUE testing sites, the Guild established a formal relationship with the Object Management Group.
As part of the program’s initial introduction, selected individuals will be given the opportunity to take a beta version of the certification exam at no charge. The results of beta program testing will enable the Guild to collect statistical data to ensure that the official version of the exam meets the highest quality standards. The Business Architecture Guild is now taking applications for its Certified Business Architect (CBA)® beta exam.
The Guild will provide additional updates on the program’s progress throughout the beta period. You can find additional information on the Certified Business Architect (CBA)® program by going to www.businessarchitectureguild.org. To learn more, go to the Certification Home page. To apply to participate in the beta exam, go to the Certification Beta Exam Information and Application page. Note that the beta and regular versions of the exam are open to members of the Business Architecture Guild.
About the Business Architecture Guild
The primary purpose of the Business Architecture Guild is “to promote best practices and expand the knowledgebase of the business architecture discipline.” The Guild is an international, not-for-profit, member-based organization that provides valuable resources to business architecture practitioners and others interested in the field. The Business Architecture Guild is the source of “A Guide to the Business Architecture Body of Knowledge™ (BIZBOK® Guide)”, produced and managed by members of the Business Architecture Guild.
For more information, visit www.businessarchitectureguild.org.
About Pearson VUE and the OMG
Pearson VUE is the leading provider of global computer-based testing solutions for information technology, academic, government and professional organizations. home.pearsonvue.com
The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium that was founded in 1989. www.omg.org
domingo, 12 de abril de 2015
jueves, 9 de abril de 2015
miércoles, 8 de abril de 2015
lunes, 6 de abril de 2015
Enterprise Architect Job
Are you ready to seize an opportunity to work with established and innovative enterprises in a long-term relationship? Looking to work closely with top Line of Business and IT Executives in large Enterprises, to accelerate the achievement of business objectives through a roadmap of pragmatic technology adoption? Can you do this in a heterogeneous IT environment involving multiple platforms and technologies? Want to connect the solutions you envision to the business and measure impact to the bottom line of your customer? Interested in leveraging your abstract thinking skills and employing strong architectural skills to create innovative solutions for the largest organizations in the world?
In this pivotal role within our Enterprise Strategy business, you’ll deliver advisory and planning services to Microsoft’s top enterprise customers. The Enterprise Architect enables customers to achieve their most challenging business and organizational goals whilst leveraging maximum value from their current and future investments in Microsoft technologies. Through a programmatic approach and objective assessment of the customer’s existing business imperatives and IT investments, the Enterprise Architect systematically plans, orchestrates, and contributes to the development and execution of their strategic technology initiatives so that they align with their broader business goals in an innovative fashion.
We know you are already well networked and, in addition to continuing to build your own network of contacts, you’ll be provided with an extensive network of colleagues with complementary competencies - you really will be joining a top performing team of passionate industry thought leaders who are the best in the business
The sections below identify the key areas and offer insight into the more common activities:
- Relationship-driven differentiation: As the primary delivery resource for the Enterprise Strategy business, what you provide is unique and available only from Microsoft. You’ll advocate on behalf of the customer back into the Microsoft organization and maximize the value delivered from the relationship. Core activities include:
o Arranging Executive Briefing Center visits and bi-directional connection with Microsoft Product Development Groups and many other teams and communities.
o Facilitating the Customer’s uptake of Technology Adoption Programs for early advantage from pre-released Microsoft Products.
o Harnessing insights from groups like Microsoft Research, one of the largest sponsored technology research organizations worldwide. You also have access to the ‘Library’, a catalog of reference architectures, blueprints, industry insights and benchmark data that adds unique value.
o Facilitating customer IT staff development.
- Architecture & Consulting. The role takes a principled approach first to understand the customer’s needs and then to develop roadmaps of change that realize value from their Microsoft investment across a heterogeneous IT environment. Activities include:
o Creating business case development and benefits management programs that define, track and report accrued value through the optimal application of IT to business challenges.
o Orchestrating and/or designing and architecting solutions that leverage both the investment made in the Microsoft Enterprise Agreement and the customer’s current heterogeneous IT environment in the best interests of the customer, driven through a program of orchestrated change and drawing from the collective know-how of Microsoft.
o Providing portfolio governance and oversight to drive lifecycle optimization and alignment across all Microsoft-related strategy and planning initiatives.
- Teaming to accelerate value: When a Microsoft customer invests in an Enterprise Agreement license with Microsoft, the Architect, Enterprise Architecture accelerates the time-to-value by aligning the technology deployment and business adoption plans with customer organizational objectives. Activities to support this objective include:
o Creating architectural and technology roadmaps that result in stronger business/IT alignment and that drive adoption and value from the Enterprise Agreement.
o Orchestrating the use of the Microsoft network of resources formally from within the Advisor’s individual engagement. This can range from formal Solution Architecture through to general technology consulting and beyond. Likewise an Advisor may be called on by colleagues to contribute from their area of specialization in other large engagements or to team with the support team around specific customer initiatives.
- Practice development: This role will contribute to the growth and maturity of the local and international communities provide mentorship, foster knowledge transfer, and lead by example. In addition, opportunities exist to drive IP development and reuse initiatives and drive best or proven practice in architecture, planning, and customer engagement.
- Business development: This role will be expected and have the opportunity to bring their years of experience and expertise to bear on local business development opportunities and contribute to thought leadership within and across both their local Microsoft business and more broadly across other Microsoft businesses.
In addition to the above activities, it is expected that the successful candidate will have significant experience in at least one specialization from the three categories below:
- Industry: The following are higher priorities: Public Sector; Banking; Telco; Manufacturing; Energy
- Microsoft Strategic priorities: Cloud/S+S; Enterprise level / Mission Critical Applications; Optimized Desktop; Unified Communications and Collaboration
- Architect, Enterprise Architecture Specializations:
o Business Value analysis and benefits management
o Enterprise-level Architecture
o Business Architecture
o Information Architecture
o IT Governance
o IT Portfolio Lifecycle Optimization
o Organizational Change Management
o Organizational Design
o IT-led Business Innovation
This role understands interoperability issues and the strengths and weaknesses of platforms and products, and is able to provide a trusted voice at the decision-making table. Typically with IT sponsorship, they develop relationships with key line-of-business executives, putting them in position to translate early business needs and insights into actionable IT strategy and assist IT in driving these initiatives to early results and business value. This work encompasses a solid understanding of business and IT strategy, a principled approach to broader architectural challenges and opportunities, and a great grasp of technology and solutions.
If you meet the above profile, we’d really like to talk with you.
Qualifications and Experience:
- Must have a combination of a degree (Computer Science, Social Science or Business), and equivalent work experience
- At least 8 - 10 years related IT experience
- Must have a proven record of delivering business value from Information Technology at an executive level
- Candidates must have a deep understanding of markets, industries, business, customers, and technology. Work experience should involve a mix of business and technology consulting across the lifecycle of Information Technology (examples may include assessment and analysis, design, business case development, architecture, envisioning, planning, deployment, benefits analysis, and management)
- The ability and background experience to provide leadership in the practice, and a demonstrated effectiveness in consulting and client management
- Executive-level interpersonal and writing skills
- Experience at forming and leading virtual teams
- Fluent In Spanish and English
Microsoft is an equal opportunity employer and supports workforce diversity. All applications for vacant positions will be welcomed and will be considered on the relative merits of the applicant against the role profile for the position regardless of colour, race, nationality, ethnic origin, sex, gender, sexual orientation, marital status, disability, parental responsibilities, age, religion, or belief.
miércoles, 1 de abril de 2015
Download a Best Practice Approach For Your Digital Transformation
http://www.cxo-transform.com/101-2/
Leveraging the Digital Capability Framework (DCF) and the Business Transformation Management Methodology (BTM²)
Step 1: Digital Capabilities Assessment
Step 2: Digital Use Case Creation and Mapping
Step 3: Benefit Analysis
Step 4: Business Priority Assessment
Step 5: Digital Transformation Roadmap
Step 6: Business Case Development
Step 7: Strategic Management Tool Selection
Step 8: Business Transformation Methodology Selection
Step 9: Orchestrate The Transformation
Step 10: Acquire Knowledge Through Recommended Reading
Suscribirse a:
Entradas (Atom)