lunes, 28 de diciembre de 2015

sábado, 19 de diciembre de 2015

Change Management

http://www.projectmanagement.com/articles/311176/Architecting-the-Organization-for-Change

IT Architecture Skills

http://respect-architects.blogspot.se/2015/09/looks-like-we-need-it-architect-right.html

Cobit Course

http://www.webagesolutions.com/courses/WA1947-cobit-foundation-course-with-the-cobit-games


Gr@bPizza

http://www.gamingworks.nl/isaca-round-table-marriage-counselling-using-cobit/

https://www.linkedin.com/pulse/co-creating-future-management-exciting-developments-paul-wilkinson

viernes, 18 de diciembre de 2015

Digital Transformation Links

https://www.cxotalk.com/

http://www.zdnet.com/article/business-transformation-and-the-digital-cio/

http://www.snaplogic.com/blog/_infographic-cios-getting-smact/


IT4IT Links

https://www2.opengroup.org/ogsys/jsp/publications/PublicationsBySubjectType.jsp?limit=mainSubjectId-10110:secSubjectId-10110:statusId-1:useInPublications-Y&title=IT4IT


http://www.opengroup.org/IT4IT/testimonials

https://www.goodelearning.com/courses/it4it/it4it-foundation?utm_spirce=CM&utm_medium=IT4IT-Awareness&utm_content=Register-Interest&utm_campaign=15-12-2015

jueves, 10 de diciembre de 2015

Business Capability Modeling made easy!

http://enterpriseevolver.com/business-capability-modeling-made-easy-with-enterprise-evolver/#prettyPhoto

martes, 1 de diciembre de 2015

Disruption and Emergence: What does it mean for Enterprise Architecture?

http://blog.cutter.com/2015/11/20/disruption-and-emergence-what-does-it-mean-for-enterprise-architecture/

Designing the Business of IT

https://www.linkedin.com/pulse/designing-business-danny-graham

PRINCE 2

https://projectmanagers.org/learn-prince2-in-7-pictures-last-one-in-the-series/

http://www.knowledgetrain.co.uk/prince2-processes-ebook.php


IT4IT: what you need to know

IT4IT: what you need to knowç



http://www.lean4it.com/2015/11/it4it-what-you-need-to-know.html

viernes, 27 de noviembre de 2015

jueves, 26 de noviembre de 2015

A SOA Journey Using the TOGAF ADM

https://blogs.perficient.com/ibm/2014/03/06/a-soa-journey-using-the-togaf-adm-part-2/

http://www.ariscommunity.com/users/etienne/2013-05-06-integrating-togaf-adm-archimate-bpmn-uml-your-sdlc-part-2


Equipping Your Toolbox with TOGAF Building Blocks

http://archvalue.com/equipping-your-toolbox-with-togaf-building-blocks/

lunes, 23 de noviembre de 2015

DevOps: rompiendo las barreras entre desarrollo y operaciones bajo el marco de la agilidad, la ISO 20000 y la ISO 15504/12207

http://www.mkm-pi.com/byte-ti/devops-rompiendo-las-barreras-entre-desarrollo-y-operaciones-bajo-la-el-marco-de-la-agilidad-la-iso-20000-y-la-iso-1550412207/

Capability LInks

https://enklare.wordpress.com/2015/11/09/capability-map-patterns-l0/




https://enklare.wordpress.com/2015/06/15/the-capability-inventory/


https://enklare.wordpress.com/2015/01/07/the-capability-canvas/


Risk Links

http://www.pilar-tools.com/es/index.html?tools/pilar/index.html

http://www.auditool.org/blog/control-interno/2545-tecnicas-de-evaluacion-de-riesgos-analisis-preliminar-de-peligros


martes, 10 de noviembre de 2015

domingo, 18 de octubre de 2015

Driving Business Outcomes with Enterprise Architecture as a Knowledge Hub

http://blog.bizzdesign.com/driving-business-outcomes-with-enterprise-architecture-as-a-knowledge-hub?url=/blog/driving-business-outcomes-with-enterprise-architecture-as-a-knowledge-hub/





EA Software

http://www.enterprise-architecture.info/EA_Tools.htm

miércoles, 14 de octubre de 2015

Digital Transformation Links

http://www-05.ibm.com/es/businessconnect/index.html?S_TACT=BP_EFOR&S_TACT=BP_EFOR
https://www.gov.uk/transformation
https://www.gov.uk/transformation

http://www.i-scoop.eu/digital-transformation/
https://www.gov.uk/transformation


http://www.entrepreneurial-insights.com/digital-transformation-what-why-how/
https://www.capgemini-consulting.com/digital-transformation
http://sloanreview.mit.edu/article/the-nine-elements-of-digital-transformation/
http://www.theagileelephant.com/what-is-digital-transformation/
http://www.theguardian.com/media-network/media-network-blog/2013/nov/21/digital-transformation

viernes, 2 de octubre de 2015

THE TRANSFORMATIONAL ENTERPRISE BUSINESS ANALYST

http://www.batimes.com/kathleen-hass/the-transformational-enterprise-business-analyst.html?utm_content=buffer21df3&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

jueves, 24 de septiembre de 2015

martes, 22 de septiembre de 2015

Como Implementar un Análisis Modal de Fallos y Efectos (AMFE) y Planes de Control

http://www.sistemasycalidadtotal.com/calidad-total/como-implementar-un-analisis-modal-de-fallos-y-efectos-amfe-y-planes-de-control/

lunes, 21 de septiembre de 2015

The Future of IT Governance

http://www.isaca.org/Blogs/424236/Lists/Posts/ViewPost.aspx?ID=3&RootFolder=%2FBlogs%2F424236%2FLists%2FPosts

Usando Líneas Base en Microsoft Project

http://jose-barato.blogspot.com.es/2015/09/usando-lineas-base-en-microsoft-project.html

jueves, 10 de septiembre de 2015

Educa

http://www.educaragon.org/GestionPersonal/nodo.asp?id=1509&ultimo=1496&padre=1494

lunes, 7 de septiembre de 2015

lunes, 31 de agosto de 2015

IT4IT: L’enfant terrible

IT4IT: L’enfant terrible

http://www.gobiernotic.es/2015/04/it4it-lenfant-terrible.html

Putting the 'B' in BRM

Putting the 'B' in BRM

http://www.cio.com.au/article/542100/putting_b_brm/

Agile, TOGAF and Enterprise Architecture: Will They Blend?

https://www.itpreneurs.com/blog/agile-togaf-and-enterprise-architecture-will-they-blend/

¿Qué es TOGAF?

http://www.colombiadigital.net/actualidad/articulos-informativos/item/8163-que-es-togaf.html

Helping Hands - Marketing Enterprise Architecture

Helping Hands - Marketing Enterprise Architecture


https://www.linkedin.com/pulse/helping-hands-marketing-enterprise-architecture-nick-malik

SA in COBIT 5 EA framework drive

http://www.itweb.co.za/index.php?option=com_content&view=article&id=145655%3ASA-in-COBIT-5-EA-framework-drive&catid=154

The Business Transformation Manager Challenge

http://www.robllewellyn.com/business-transformation-manager/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Plantilla de caso de negocio para proyectos

http://www.pmoinformatica.com/2013/09/plantilla-caso-de-negocio.html?utm_content=bufferd6ee6&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

Essential Transformation Roles and Capabilities

http://www.robllewellyn.com/transformation-roles/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

5 STEPS TO BECOMING AN ENTERPRISE ARCHITECTURE NINJA

http://avolutionsoftware.com/about-us/news/5-steps-to-becoming-an-enterprise-architecture-ninja/

CAPABILITY ARCHITECTURE AND MICROSERVICES

https://enklare.wordpress.com/2015/06/30/capability-architecture-and-microservices/

lunes, 24 de agosto de 2015

CIO Review

http://magazine.cioreview.com/July-2015/EA/

SNA

http://www.snatinc.com/content/enterprise-architecture

What exactly is an Enterprise Architect versus a Solution Architect?

https://www.linkedin.com/pulse/what-exactly-enterprise-architect-versus-solution-johan-carstens

It's actually quite simple. I propose that a Solution Architect is a project team role that is responsible for the system quality of the solution being delivered to the business. I also propose that an Enterprise Architect is a planning role that is responsible for identifying the future state of an organization's IT environment and engage wherever and whomever necessary to help guide project team's to deliver toward it. There are formal definitions out there.
I get the impression there are people out there that think an Enterprise Architect is a Solution Architect but work in enterprise organizations. I also have the impression that there are people out there that think an Enterprise Architect is someone who only works with Powerpoint, collects information from Solution Architects and spends the majority of their time with the business leads and governance boards merely reporting on the information they've pulled together. Although I recognize that there are organizations in situations that implement Enterprise Architect and Solution Architect like this, I believe they are inefficient and are likely in a transition state to the more efficient role definitions I proposed earlier.
Taking my proposed definitions, I'd like to identify architect subtypes to help support the difference between them to help describe what I'm talking about.
A Solution Architect may have a number of different types of architects working for him/her to help accomplish their task for delivering a high quality solution. For example, s/he might have an Infrastructure Architect to manage the architecture of the solution's hardware configuration so that the solution meets the Quality of Service business and IT requirements while at the same time represents the optimum way to deploy the solution into the target production environments.
There also might be a need for 'specialist' architects depending on the complexities of the business requirements or the target production environment. Such 'specialist' architects usually are called Domain Architects and examples include; Security Architect, Technology Architect (ie architects that specialize in a specific product or technology), Vertical Architects (ie architects that specialize in systems that are specialized in particular industry verticals such as Financial Services Industry, Telecommunications, Public Sector, etc).
An Enterprise Architect may have also have a number of different types of architects in order to piece together a coherent, actionable future state architecture which can easily map to business strategy, be consumed by project teams and be a major contribution in governance activities.
For example, an Enterprise Architect may have Business Architects which document Business Strategies, Program and Project Portfolios, Business Processes and Roles as well as a number of other artifacts to help analyze them such as mapping artifacts.
An Enterprise Architect may also have Information Architects who document the information models such as Data Subject Areas, Data Facets, Business Objects, Business Entities and Data Entities with the intention of supporting the Business Processes while at the same time designing for data integrity and data quality for the enterprise.
An Enterprise Architect may also have Infrastructure Architects (aka Technology Architects) that focus on the hardware and operating system-level infrastructure.
Lastly, an Enterprise Architect may also have Solution Architects (aka Enterprise Solution Architects and Enterprise Application Architects) who focus on pulling all of the other Enterprise Architecture information together to shape the future state application system architecture.
Here is one place where I think there is confusion by many. You see, I described a Solution Architect at the project-level and an Enterprise Solution Architect across the enterprise and both share the words 'Solution Architect' in their role. They have VERY different purposes but are very complimentary. Could it be that simple of a reason why confusion exists? It just might be.
An Enterprise Solution Architect and project Solution Architect roles are very complimentary and because this relationship is of particular interest to me I'd like to take a moment and propose how they are to work together.
 I propose that the Enterprise Solution Architect be involved at the earliest point a new business initiative is created and do very high-level 'solutioning' via whiteboard and reference to future state architecture elements. Then, when the business initiative gains momentum and is backed by Enterprise Architecture future state concepts, the core project team is formed and the project Solution Architect takes over to be responsible for the solution. The Enterprise Solution Architect becomes a member of the project Solution Architects team and is responsible for the system integration architecture where the solution requires integration between enterprise systems as well as be responsible to provide future state system architecture guidance to help the project Solution Architect make decisions on which systems to commit to using in the solution. The Enterprise Solution Architect then is involved in governance boards to inform decision-makers with future-state architecture artifacts to help justify major technology, system, or business value decisions. That’s it.
As a quick summary, project Solution Architects and Enterprise Architects are different in that they have very different purposes. They are highly complementary in that Solution Architects focus on delivery of solutions and Enterprise Architects focus on supporting them by documenting future state, participating on their teams and being involved in governance activities.
 If you need a strong and experienced Enterprise Architect "consultant" to lead or steer challenging IT projects including technology road-maps feel free to contact me.

Johan Carstens - Enterprise Architect

Milton Keynes - UK 
 Hi All, 
Thank you for the great feedback and forwarding on this post, It would be very interesting to understand the key benefits you feel and Enterprise Architecture brings to your organisation and the role Enterprise Architecture play in the business as a whole. 

BRM Explorer Compass

http://archive.constantcontact.com/fs121/1112999892084/archive/1121709207561.html

BRM and BA Collaboration to Maximize the Value of IT Investments

http://brminstitute.org/brm-and-ba-collaboration-to-maximize-the-value-of-it-investments/

THE LEADERSHIP SERIES

http://theleadershipseries.co/category/the-video-series/

Business Relationship Management (BRM) in 3 minutes

http://blog.apmg-international.com/index.php/2015/03/11/business-relationship-management-brm-in-3-minutes/

BRM Videos

http://www.themerlyngroup.com/resources/

Is the CIO the ultimate BRM?

http://jeremypaulbyrne.blogspot.com.es/2015/07/CIO-the-ultimate-BRM.html

viernes, 31 de julio de 2015

martes, 28 de julio de 2015

Avolution Blog

HOW TO BUILD AN EA ROADMAP: 4 STYLES TO CONSIDER

http://www.avolutionsoftware.com/about-us/news/how-to-build-an-ea-roadmap-4-styles-to-consider/


5 STEPS TO ACHIEVING A GREAT CUSTOMER EXPERIENCE THROUGH DIGITAL TRANSFORMATION






http://www.avolutionsoftware.com/about-us/news/5-steps-to-achieving-a-great-customer-experience-through-digital-transformation/


lunes, 27 de julio de 2015

A guide to PRINCE2 for PMP® and CAPM® Credential Holders

http://www.knowledgetrain.co.uk/prince2-guide-for-pmp-and-capm-credential-holders.php

COBIT 5 Links


Applying COBIT in a Government Organization

http://www.isaca.org/COBIT/focus/Pages/applying-cobit-in-a-government-organization.aspx?cid=edmi_1108854&appeal=edmi?cid=edmi_1108855&appeal=edmi

5 Common Mistakes in Adopting COBIT 5

http://www.isaca.org/COBIT/focus/Pages/5-common-mistakes-in-adopting-cobit-5.aspx?cid=edmi_1108852&appeal=edmi?cid=edmi_1108855&appeal=edmi

Bahrain Government Embraces COBIT 5 Governance and IT Management

http://www.isaca.org/COBIT/focus/Pages/bahrain-government-embraces-cobit-5-governance-and-it-management.aspx?cid=edmi_1108851&appeal=edmi?cid=edmi_1108855&appeal=edmi

Are You a COBIT 5 Expert, Champion or Consultant? Be Aware!

http://www.isaca.org/COBIT/focus/Pages/are-you-a-cobit-5-expert-champion-or-consultant-be-aware.aspx?cid=edmi_1108844&appeal=edmi?cid=edmi_1108855&appeal=edmi

COBIT 5 and ITIL Adaptation at a Saudi Municipality

http://www.isaca.org/COBIT/focus/Pages/cobit-5-and-itil-adaptation-at-a-saudi-municipality.aspx?cid=edmi_1108850&appeal=edmi?cid=edmi_1108855&appeal=edmi

Lessons Learned From the COBIT Conference

http://www.isaca.org/COBIT/focus/Pages/lessons-learned-from-the-cobit-conference.aspx?cid=edmi_1108849&appeal=edmi?cid=edmi_1108855&appeal=edmi

State and Impact of GEIT in Organizations: Key Findings of an International Study

http://www.isaca.org/COBIT/focus/Pages/state-and-impact-of-geit-in-organizations-key-findings-of-an-international-study.aspx?cid=edmi_1108845&appeal=edmi?cid=edmi_1108855&appeal=edmi

Using Versus Implementing COBIT 5

http://www.isaca.org/COBIT/focus/Pages/using-versus-implementing-cobit-5.aspx?cid=edmi_1108846&appeal=edmi?cid=edmi_1108855&appeal=edmi


lunes, 13 de julio de 2015

lunes, 6 de julio de 2015

Business Transformation Management Methodology (BTM2)

Business Transformation Management Methodology (BTM2)

https://support.sap.com/support-programs-services/methodologies/BTM2.html

Questioning the Role of the Business Relationship Manager

http://vaughanmerlyn.com/2012/03/06/questioning-the-role-of-the-business-relationship-manager/

lunes, 22 de junio de 2015

BTM Links

Business Transformation Types

http://www.cxo-transform.com/business-transformation-types/


What is The Business Transformation Management Methodology?

http://www.cxo-transform.com/business-transformation-management-methodology/


What is Business Transformation?

http://www.cxo-transform.com/what-is-business-transformation/

martes, 16 de junio de 2015

University Enterprise Architecture Guiding Principles: 3 Examples

http://www.corso3.com/blog/ea/university-enterprise-architecture-guiding-principles-examples-examples?utm_source=hs_email&utm_medium=email&utm_content=18267636&_hsenc=p2ANqtz-8vCpRO7IOQRJDt9djucGjLeJh-4LPUSrQkOAEdmP4WYxKeCZ-0E4Xz7mutD9dvX0O4NoqR-NgGWay54pXmSiIZi6ZRKA&_hsmi=18267636

jueves, 28 de mayo de 2015

miércoles, 27 de mayo de 2015

COBIT 5 and ITIL Adaptation at a Saudi Municipality


http://www.isaca.org/COBIT/focus/Pages/cobit-5-and-itil-adaptation-at-a-saudi-municipality.aspx?cid=sm_1107871&appeal=sm&utm_referrer=http%3A%2F%2Fm.facebook.com

miércoles, 20 de mayo de 2015

Making Architecture and BRMs Successful

http://iasaglobal.org/making-architecture-and-brms-successful/

Por que necesitas arquitectura empresarial y togaf

http://www.slideshare.net/leonardoramirezgonzalez/por-que-necesitas-arquitectura-empresarial-y-togaf

A two-speed IT architecture for the digital enterprise

http://www.mckinsey.com/insights/business_technology/a_two_speed_it_architecture_for_the_digital_enterprise

Who put the “Enterprise” in Architecture?

http://www.evernden.net/who-put-the-enterprise-in-architecture/

http://www.evernden.net/resources/togaf-videos/

http://www.evernden.net/resources/togaf-blog/

Bahrain Government Embraces COBIT 5 Governance and IT Management

http://www.isaca.org/COBIT/focus/Pages/bahrain-government-embraces-cobit-5-governance-and-it-management.aspx?cid=sm_1107744&appeal=sm&utm_referrer=http%3A%2F%2Fm.facebook.com

jueves, 14 de mayo de 2015

Hot Jobs: Business Relationship Manager

http://www.cio.com/article/2438140/it-organization/hot-jobs--business-relationship-manager.html

The CEO's Gap Between Strategy & Execution

https://www.linkedin.com/pulse/20140814081645-3192694-the-ceo-s-gap-between-strategy-execution

BAG CERTIFICATION PROGRAM

http://www.businessarchitectureguild.org/?page=Certification

http://www.businessarchitectureguild.org/page/CBAProgram/

http://www.businessarchitectureguild.org/BlankCustom.asp?page=CBAdomainsandobjec

 

Business Architecture Certification

The Business Architecture Guild will offer a certification which will further the advancement of the business architecture profession by providing a way to measure and document the knowledge and skills necessary to be recognized as a competent practitioner. Certification also helps organizations define job descriptions, assess job candidates and employee performance, and structure programs that enable business architecture professionals to enhance their knowledge and skills.

Certification holders will be able to obtain recognized competency in business architecture from the Business Architecture Guild that demonstrates their qualifications to engage in and practice the profession. Certification will cover the following practice and disciplinary domains.

1. Business Architecture Foundational Concepts: The section assesses basic understanding of general business architecture concepts, core versus extended business mapping disciplines, scenario use and context, and overall value proposition.

2. Business Architecture Core Mapping Knowledge: Core mapping disciplines test one’s knowledge of creating and using capability, value, organization and information maps and the interaction among these disciplines.

3. Business Architecture Extended Mapping Knowledge: The extended mapping disciplines section examines one’s knowledge of strategy mapping, stakeholder mapping, initiative mapping, product and service mapping, and policy mapping.

4. Business Architecture Alignment with Related Business Disciplines: This section determines one’s knowledge of business architecture as it relates to related business disciplines that include business model alignment, business process management, case management and business requirements analysis.

5. Business Architecture & Business Performance Analysis: This section examines one’s understanding of using business architecture to assess how well each aspect of the business is performing and includes performance metrics, initiative assessments and portfolio planning.

6. Business Architect Role: This section assesses one’s knowledge of the business architect’s role, responsibilities, competencies and interactions with related roles.

7. Business Architecture Governance: This section assesses one’s knowledge of business architecture team setup, organizational alignment, stakeholder engagement and all of the components necessary to successfully deploy, mature, measure and sustain a business architecture program.

8. Business Architecture & IT Architecture Alignment: This section determines one’s ability to leverage business architecture in IT architecture assessments, portfolio management, engagement with application, data and solution architects, and business / IT transformation initiatives.

9. Business Architecture Situation & Scenario Usage: This section tests one’s understanding of how to apply business architecture in various business situations and include issue analysis and resolution, impact analysis, change management, customer experience and other common business scenarios.

10. Business Architecture Infrastructure Management: Infrastructure management examines one’s ability to manage and package business architecture artifacts and reporting and includes a basic understanding of the role of knowledgebase structure and tooling considerations.

 

Business Architecture Guild:
Certified Business Architect
(CBA)® Program

Certified Business Architect(CBA)® – Certification Exam Domains & Objectives

This document provides defines the domain categories and related objectives for each business architecture certification exam domain category.

1.0 Business Architecture Foundational Concepts: The section assesses basic understanding of general business architecture concepts, core versus extended business mapping disciplines, scenario use and context, and overall value proposition.

1.1 Objective: Test candidate’s knowledge of business architecture’s purpose, scope, principles and value proposition

1.2 Objective: Test candidate’s knowledge of the business architecture ecosystem

1.3 Objective: Test candidate’s knowledge of the Business Architecture Framework

2.0 Business Architecture Core Mapping Knowledge: Core mapping disciplines test one’s knowledge of creating and using capability, value, organization and information maps and the interaction among these disciplines.

2.1 Objective: Test candidate’s knowledge of capability mapping

2.2 Objective: Test candidate’s knowledge of value mapping

2.3 Objective: Test candidate’s knowledge of organization mapping

2.4 Objective: Test candidate’s knowledge of information mapping

3.0 Business Architecture Extended Mapping Knowledge: The extended mapping disciplines section examines one’s knowledge of strategy mapping, stakeholder mapping, initiative mapping and product and service mapping.

3.1 Objective: Test candidate’s knowledge of strategy mapping

3.2 Objective: Test candidate’s knowledge of stakeholder mapping

3.3 Objective: Test candidate’s knowledge of initiative mapping

3.4 Objective: Test candidate’s knowledge of product mapping

3.5 Objective: Test candidate’s knowledge of policy mapping

4.0 Business Architecture Alignment with Related Business Disciplines: This section determines one’s knowledge of business architecture as it relates to related business disciplines that include business model alignment, business process management, case management and business requirements analysis.

4.1 Objective: Test candidate’s knowledge of business architecture alignment with business model frameworks

4.2 Objective: Test candidate’s knowledge of business architecture alignment with business process modeling

4.3 Objective: Test candidate’s knowledge of business architecture’s use in conjunction with business requirements analysis

4.4 Objective: Test candidate’s knowledge of business architecture alignment with case management

4.5 Objective: Test candidate’s knowledge of business architecture alignment with Lean/Six Sigma

5.0 Business Architecture & Business Performance Analysis: This section examines one’s understanding of using business architecture to assess how well a business is performing and includes performance metrics, initiative assessments and portfolio planning.

5.1 Objective: Test candidate’s knowledge of basic performance management concepts

5.2 Objective: Test candidate’s knowledge of heat mapping usage and practice in business architecture

5.3 Objective: Test candidate’s knowledge of business performance measurement

5.4 Objective: Test candidate’s knowledge of how business performance management is applied

6.0 Business Architect Role: This section assesses one’s knowledge of the business architect’s role, responsibilities, competencies and interactions with related roles.

6.1 Objective: Test candidate’s knowledge of his or her role in stakeholder and relationship management

6.2 Objective: Test candidate’s knowledge of the business architect as a leader and a facilitator

6.3 Objective: Test candidate’s knowledge of his or her role as advisor, mentor

6.4 Objective: Test candidate’s knowledge of communicating, persuading and presenting

6.5 Objective: Test candidate’s knowledge of the competencies of a business architecture practitioner

7.0 Business Architecture Governance: This section assesses one’s knowledge of business architecture team setup, organizational alignment, stakeholder engagement and all of the components necessary to successfully deploy, mature, measure and sustain a business architecture program.

7.1 Objective: Test candidate’s knowledge of the roles involved in business architecture governance

7.2 Objective: Test candidate’s knowledge of business architecture governance structures

7.3 Objective: Test candidate’s knowledge of business architecture team purpose and principles

7.4 Objective: Test candidate’s knowledge of how to scale business architecture efforts

7.5 Objective: Test candidate’s knowledge of applying business architecture in an organization

7.6 Objective: Test candidate’s knowledge of assessing the maturity of a business architecture deployment

8.0 Business Architecture & IT Architecture Alignment: This section determines one’s ability to leverage business architecture in IT architecture assessments, portfolio management, engagement with application, data and solution architects, and business / IT transformation initiatives.

8.1 Objective: Test candidate’s knowledge of business and IT architecture alignment

8.2 Objective: Test candidate’s knowledge of leveraging business architecture under the broader perspective of enterprise architecture

8.3 Objective: Test candidate’s knowledge of the use of business architecture for application portfolio management

8.4 Objective: Test candidate’s knowledge of the role of business architecture in the context of services-oriented architecture (SOA)

8.5 Objective: Test candidate’s knowledge of business architecture and data management and data architecture

8.6 Objective: Test candidate’s knowledge of business architecture’s role in business / IT transformation

9.0 Business Architecture Situation & Scenario Usage: This section tests one’s understanding of how to apply business architecture in various business situations and include issue analysis and resolution, impact analysis, change management, customer experience and other common business scenarios.

9.1 Objective: Test candidate’s knowledge of how to use business architecture in various assessment situations

9.2 Objective: Test candidate’s knowledge of how business architecture applies to transformative scenarios

9.3 Objective: Test candidate’s knowledge of how business architecture applies to smaller scale, tactical scenarios

9.4 Objective: Test candidate’s knowledge of where various aspects of business architecture would be applied in certain situation analysis and in what context

10.0 Business Architecture Infrastructure Management: Infrastructure management examines one’s ability to manage and package business architecture artifacts and reporting and includes a basic understanding of the role of knowledgebase structure and tooling considerations.

10.1 Objective: Test candidate’s knowledge of business architecture knowledge management and related knowledgebase

10.2 Objective: Test candidate’s knowledge of automation options for managing the business architecture

Taking a Careful Slice – Defining Business Architecture

he definition I’m considering at this time is:

Business Architecture is
1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support. [Updated, 5 Sept 12]
2. A subset of the architectural description of an enterprise sufficient to produce models that meet the functional, motivational, and alignment concerns of stakeholders. [Updated 11 Sept 12]

http://blogs.msdn.com/b/nickmalik/archive/2012/08/27/taking-a-careful-slice-defining-business-architecture.aspx

Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.

http://blogs.msdn.com/b/nickmalik/archive/2010/08/08/a-reasonable-canonical-definition-of-enterprise-architecture.aspx

CX = BRM + SLM?

https://www.axelos.com/news/blogs/may-2015/cx-brm-slm

miércoles, 13 de mayo de 2015

ARCHIBUS Product Architecture

http://www.archibus.com/ai/abizfiles/v20.1_help/system-management-help/afm-sysman_Left.htm#CSHID=J2EE%2FARCHIBUS_Product_Architecture.htm|StartTopic=Content%2FJ2EE%2FARCHIBUS_Product_Architecture.htm|SkinName=NewBlueSkin

Using Enterprise Architecture to Improve Governance & Agility at the Same Time

http://community.mega.com/t5/Blog/Using-Enterprise-Architecture-to-Improve-Governance-amp-Agility/ba-p/10780

What is Enterprise Architecture?

https://www.goodelearning.com/videos/what-is-enterprise-architecture

Business Architect, Enterprise Architect and Business Transformation

http://community.biz-architect.com/about-ba/business-architect-enterprise-architect-business-transformation/

http://www.bainstitute.org/resources/articles/business-architect-enterprise-architect-and-business-transformation

sábado, 2 de mayo de 2015

Establishing a Governance and Management Structure for E-commerce Using COBIT 5

http://www.isaca.org/COBIT/focus/Pages/establishing-a-governance-and-management-structure-for-e-commerce-using-cobit-5.aspx?cid=edmi_1107257&appeal=edmi

The Borderless Enterprise (Architecture)

http://community.mega.com/t5/Blog/The-Borderless-Enterprise-Architecture/ba-p/10438

Enterprise Architecture: The CIO’s Snow Blower of Business Innovation

http://community.mega.com/t5/Blog/Enterprise-Architecture-The-CIO-s-Snow-Blower-of-Business/ba-p/10609

EAbok

http://eabok.org/

The Great Escape: “EA is not about IT!”

http://enterprisechess.com/2015/04/27/the-great-escape-ea-is-not-about-it/

Introducing – The Digital Collaboration Canvas

http://www.oscarberg.net/2015/04/introducing-digital-collaboration-canvas.html

Nine Steps to Assess GEIT Processes

http://www.isaca.org/COBIT/focus/Pages/nine-steps-to-assess-geit-processes.aspx?utm_campaign=ISACA+Main&cid=sm_1106584&utm_content=1426002590&utm_source=twitter&utm_medium=social&appeal=sm

viernes, 1 de mayo de 2015

Getting the right Architectures Roles

image

image

https://www.goodelearning.com/Downloads/ViewOnline?resourceFriendlyUrl=getting-the-right-architecture-roles&resourcePdf=Case%20Study%20-%20Getting%20the%20right%20Architecture%20Roles.pdf

Fast Track to Business Capability Planning

http://info.troux.com/fast-track-capability-based-planning2015?utm_campaign=fy15q2_webinar_expertbrief_belville_noshow&utm_medium=email&utm_source=Eloqua&elqTrackId=C555598CD8237BFAA22C3D316D534E65&elq=44db12cb032842bf8061591d80210b1f&elqCampaignId=417&elqaid=1750&elqat=1

IT Related Architecture Roles for Recruiters and Managers

 

https://www.linkedin.com/pulse/architecture-roles-matthew-kern-msea-cea-pmp-itil-cissp-issap

What is an Enterprise Architecture Maturity Model?

http://blogs.informatica.com/perspectives/2015/04/06/enterprise-architecture-maturity-model/#fbid=tzMRtlacRpi

From the Editor: Business Architecture for Project Success

 

Example Architecture and Design Responsibilities

 

http://eapj.org/from-the-editor-2015-04-19/

The business architect role and the enterprise architecture of tommorrow

http://www.ebizq.net/blogs/ea_matters/2014/04/the-business-architect-role-and-the-enterprise-architecture-of-tommorrow.php

Kanban LInks

http://www.dynarax.es/descarga/36/es-Intro-Kanban.pdf

http://hipertextual.com/archivo/2013/11/que-es-kanban/

 

http://www.pdcahome.com/metodo-kanban/

5-Stage Digital Transformation Competency Framework

https://www.linkedin.com/pulse/5-stage-digital-transformation-competency-framework-david-h-deans

 

Business Architects Architect your Success

http://community.biz-architect.com/about-ba/business-architects-architect-success/

http://www.bainstitute.org/resources/articles/business-architects-architect-your-success

Tripling the Odds of Transformation Success: A Critical Role for Business Architecture

http://community.biz-architect.com/about-ba/tripling-the-odds-of-transformation-success-a-critical-role-for-business-architecture/

Agile Enterprise Architecture – A Good to Great Evolution

http://blog.opengroup.org/2015/04/27/agile-enterprise-architecture-a-good-to-great-evolution/

Applying COBIT in a Government Organization

 

http://www.isaca.org/COBIT/focus/Pages/applying-cobit-in-a-government-organization.aspx?cid=sm_1107330&appeal=sm&utm_referrer=http%3A%2F%2Fm.facebook.com

miércoles, 29 de abril de 2015

BE A MINDFUL PROJECT MANAGER

http://www.projecttimes.com/kiron-bondale/be-a-mindful-project-manager.html

Gartner Enterprise Architecture Summit

http://www.gartner.com/technology/summits/emea/enterprise-architecture/agenda/tracks/session-casestudies.jsp

From the Editor: Business Architecture for Project Success

http://eapj.org/from-the-editor-2015-04-19/

 

Example Architecture and Design Responsibilities

Tripling the Odds of Transformation Success: A Critical Role for Business Architecture

http://eapj.org/tripling-the-odds-of-transformation-success-a-critical-role-for-business-architecture/

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?

http://it.toolbox.com/blogs/ea-matters/does-enterprise-architecture-really-enable-the-enterprise-transformation-66354

What is Decision Management?

http://www.decisionmanagementsolutions.com/what-is-decision-management/

Zachman Framework

 

https://www.dragon1.com/frameworks/zachman

Agile versus Architecture

http://it.toolbox.com/blogs/ea-matters/agile-versus-architecture-66420

ITIL , coexistencia con PMI y Ágile

http://www.slideshare.net/AlejandroJRomnPMP/itil-coexistencia-con-pmi-y-gile

¿Por qué se deben Gestionar las Empresas por Procesos?

http://blog.auraportal.com/es/por-que-se-deben-gestionar-las-empresas-por-procesos/

IT Related Architecture Roles for Recruiters and Managers

https://www.linkedin.com/pulse/architecture-roles-matthew-kern-msea-cea-pmp-itil-cissp-issap

Disruption Through Exponential Technologies

http://cxoweekly.com/disruption-through-exponential-technologies/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Digital Capability Framework Introduction

 

http://www.slideshare.net/robllewellyn/digital-capability-framework-introduction?from_m_app=ios

Lay the Foundation – Five Guiding Principles to Make Business Architecture Effective

http://community.biz-architect.com/about-ba/lay-foundation-five-guiding-principles-make-business-architecture-effective/

Strategic Planning Using Hoshin Kanri

https://www.goalqpc.com/cms/docs/whitepapers/GOALQPCHoshinWhitepaper.pdf

Lean PMO as a change agent

http://www.slideshare.net/PepeVazquezS/lean-kanbanpmo-as-change-agent

A Business Executive’s View of Business Architecture

http://www.bainstitute.org/resources/articles/business-executive%E2%80%99s-view-business-architecture

A Business Executive’s View of Business Architecture

 

http://community.biz-architect.com/about-ba/a-business-executives-view-of-business-architecture/

Microservices and the Role of the Digital Business Architect

http://community.biz-architect.com/about-ba/microservices-and-the-role-of-the-digital-business-architect/

Raconteur Business Transomation

https://raconteur.uberflip.com/i/492625-business-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

http://community.mega.com/t5/Blog/MEGA-named-leader-by-Forrester-for-Strategic-Planning-for-the-BT/ba-p/10678

Becoming a Business Transformation Master - Insights from Global Business Transformation Master (GBTM) Certification

http://www.slideshare.net/MichaelvKutzschenbac/lead-in-berlin-draft-v09

COBIT 5 Principles and Enablers Applied to Strategic Planning

http://www.isaca.org/COBIT/focus/Pages/cobit-5-principles-and-enablers-applied-to-strategic-planning.aspx?utm_campaign=ISACA+Main&cid=sm_1107213&utm_content=1429637219&utm_source=facebook&utm_medium=social&appeal=sm&utm_referrer=http%3A%2F%2Fm.facebook.com

Connecting Business Architecture to Solution Architecture

http://iasaglobal.org/articles-topics-news/connecting-business-architecture-to-solution-architecture/

lunes, 20 de abril de 2015

Leveraging Business Architecture to Improve Business Requirements Analysis

http://community.biz-architect.com/about-ba/leveraging-business-architecture-improve-business-requirements-analysis/

You Don’t Need A Digital Strategy, You Need A Digitally Transformed Company

http://techcrunch.com/2015/04/18/you-dont-need-a-digital-strategy-you-need-a-digitally-transformed-company/

Industry 4.0 – Challenging and Buzzing

http://cxoweekly.com/industry-4-0-challenging-and-buzzing/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Who Needs a Business Architecture?

http://www.bptrends.com/who-needs-a-business-architecture/

Service Management Resources

http://www.servicemanagementart.com/resources/

Are You an Enterprise Architect? Really?

 

http://eapj.org/on-slippery-ice-20141101/

The Business Designer and the Architecture

 

http://www.ebizq.net/blogs/ea_matters/2014/04/the-business-designer-and-the-architecture.php

The Best Architecture is Not Emergent

https://www.linkedin.com/pulse/20140803144645-86002769-the-best-architecture-is-not-emergent

Del manifiesto por la Informática, al manifiesto por el gobierno corporativo de las Tecnologías de la Información

http://www.ittrendsinstitute.org/perspectives/item/manifiesto-it-gcti

Enterprise Architecture Governance

0ea0153

Recruiters: Finding the "Junior Enterprise Architect"

https://www.linkedin.com/pulse/junior-enterprise-architect-kern-msea-cea-pmp-itil-cissp-issap

 

Process Tagging — A Process Classification and Categorization Concept

http://www.bpmhandbook.com/volume-1/table-of-content/process-tagging-a-process-classification-and-categorization-concept/

 

Example of Layered Architecture categories and their relations to each other Process classification and categorizationApplication of process standardization and process integration to create an operating model.Detailed example of sorting the processes according to the enterprise tiers

Enterprise Architecture Origins

 

https://www.linkedin.com/pulse/20140622135425-86002769-enterprise-architecture-origins

Bridging the gap between IT and your business

http://www.cio.co.uk/insight/change-management/bridging-gap-between-it-your-business-3607756/

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.