The document outlines six principles of IT architecture and engineering:
1) Solutions need to be architected and engineered before development to avoid becoming unusable over time. Architects should be properly employed.
2) True object-oriented design following good practices enables modularity and SOA compatibility.
3) Service-oriented architecture should be process-centric and promote collaboration between IT and business on transactional components and services.
4) Data is a key asset that requires proper management and architectural support for tasks like data mining.
5) Processes must be mapped, automated using SOA and BPMS, and continuously performance measured.
6) An enterprise taxonomy provides a categorical structure for business functions and removes boundaries for
The term Actionable Architecture moves the EA from a static project to a central platform for the capture and dissemination of IT and business process information.
In essence, EA becomes a strategic foundation for knowledgeable decision making and is based on traceable facts in a repository.
The term Actionable Architecture moves the EA from a static project to a central platform for the capture and dissemination of IT and business process information.
In essence, EA becomes a strategic foundation for knowledgeable decision making and is based on traceable facts in a repository.
Modern IT Service Management Transformation - ITIL IndonesiaEryk Budi Pratama
Presented at Online ITIL Indonesia Webinar #5.
Content:
> Setting up the context
> Understanding holistic IT Management point of view
> IT Service Management Transformation
> Key Performance Indicator (KPI)
> IT Service Catalogue
> IT Sourcing
> Agile Incident Management
How many times have you been surprised, and frustrated, to learn your IT capabilities won’t support a new or key business objective? Given the rapidly changing healthcare industry and multitude of new initiatives, this scenario happens all the time.
So how can you help ensure your IT components will work together, and can be leveraged to drive business results?
You need a blueprint — a way to align IT to the business – an IT Enterprise Architecture.
A sound Enterprise Architecture ensures your business is supported by IT components working together to deliver both a return-on-investment and projected business results.
Your Challenge:
At every organization, every day, employees at various levels make decisions on how IT is used in building, transforming, and operating the enterprise.
These decisions affect enterprise performance, both short and long term.
Our Advice:
Critical Insight
IT policies assign authority and accountability for making key IT decisions and outline mandatory process steps, but don’t say what should guide the decision-making process.
Naturally, employees in different departments and at different levels have different, often competing priorities.
Moreover, employees tend to make decisions leaning on their own assumptions as to how IT should be used by the organization. IT decisions, guided by foundational beliefs that differ, lack cohesiveness in achieving enterprise goals and require an increased IT governance effort to achieve policy compliance and realize desired business outcomes.
Impact and Result
EA principles succinctly communicate the organization’s intent as to the use of IT in building, transforming, and operating the enterprise and provide a foundation of shared beliefs that guide IT decision making across the organization.
EA principles represent a key component of IT governance and should guide the development of domain-specific policies (e.g. security policy, procurement policy) that elaborate on particular implications of principles in specific process areas.
I believe in developing enterprise architecture principles as a foundation for the definition of solutions that meet the strategic needs of an organization. These principles don’t reference technology—instead, they drive tech- nology decisions.
If used correctly, these principles allow companies to avoid building the right solution the wrong way, or worse, building the wrong solution the right way.
The focus of this article is not the Design Principles of the Architecture but the Principles that guide Enterprise Architects.
These are principles that I shared with the Enterprise Architecture teams I led
Your Challenge:
Situation
Enterprise Architecture increases the organization’s ability to provide consistent services, accessible information, scalable infrastructure, and flexible technology integration on demand. It helps bridge the gap between business and IT and creates a shared enterprise vision.
Complication
EA programs that are run without the required EA capability level are prone to failure.
EA capability optimization and EA operating model design skills are not common, as they are not everyday tasks.
Our Advice:
Critical Insight
Using this research while assessing and optimizing your EA capability will help you:
Architect the EA capability by applying four architectural perspectives: Contextual, Conceptual, Logical, and Physical. Develop an EA Operating Model starting at the contextual level, and proceeding through to the physical.
Develop a sponsored mandate for EA capability. Identify and engage EA capability stakeholders. Determine organizational scope, i.e. responsibility and authority of EA. Identify business drivers for optimizing an EA capability. Analyze organizational context. Secure executive support and authorization to execute.
Establish EA capability purpose and strategic direction. Write EA capability vision statement. Craft EA capability mission statement. Define EA capability goals and measures. Create EA principles. Assess current and determine target EA capability level.
Document EA management process. Define EA management practices. Define interactions between EA management and other processes. Define EA capability performance and value measurement approach.
Design EA organization and roles. Design EA organization structure. Define EA roles. Define required skills and proficiency levels for EA roles. Determine required EA staff capacity.
Standardize EA tools and work products. Establish an EA repository. Decide on EA tools to be used. Define EA artifacts and work products.
Develop an EA capability improvement plan. Consolidate and refine steps required to roll out the target EA operating model and improve EA capability. Draw an EA capability improvement roadmap.
The challenge of alignment, integration and change in the development of e-services has gave attention to enterprise architecture. It provide the framework of engagement and thinking tool to define, elaborate, document, agree and communicate the strategic baseline, strategic intent, strategic architecture, strategic change and strategic resources in the development and improvement of e-services within the defined context and perspectives of time, stakeholders, performance, funds, environment, leadership and technology. The shared open presentation is a product of direct engagement with people of decision and work who are enabled to participate the formulation of enterprise architecture that matters to their performance.
Introduction to Enterprise ArchitectureMohammed Omar
what is Enterprise Architecture
Enterprise Architecture Life-cycle
Enterprise Architecture benefits
Enterprise Architecture challenges
EA driven approach for IT strategy
Enterprise Architecture frameworks
Why do we Need Enterprise Architecture
Lecture 2: The Concept of Enterprise Architecture. The full teaching pack with 19 lectures, tests and other materials based on the book "The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment", which can be freely used for teaching purposes, adapted or translated with references to the original, is available on request to the author (visit http://kotusev.com)
This article describes 10 Architecture Solution Design principles to help organization focus their solution architecture teams around simple but effective design criteria.
Modern IT Service Management Transformation - ITIL IndonesiaEryk Budi Pratama
Presented at Online ITIL Indonesia Webinar #5.
Content:
> Setting up the context
> Understanding holistic IT Management point of view
> IT Service Management Transformation
> Key Performance Indicator (KPI)
> IT Service Catalogue
> IT Sourcing
> Agile Incident Management
How many times have you been surprised, and frustrated, to learn your IT capabilities won’t support a new or key business objective? Given the rapidly changing healthcare industry and multitude of new initiatives, this scenario happens all the time.
So how can you help ensure your IT components will work together, and can be leveraged to drive business results?
You need a blueprint — a way to align IT to the business – an IT Enterprise Architecture.
A sound Enterprise Architecture ensures your business is supported by IT components working together to deliver both a return-on-investment and projected business results.
Your Challenge:
At every organization, every day, employees at various levels make decisions on how IT is used in building, transforming, and operating the enterprise.
These decisions affect enterprise performance, both short and long term.
Our Advice:
Critical Insight
IT policies assign authority and accountability for making key IT decisions and outline mandatory process steps, but don’t say what should guide the decision-making process.
Naturally, employees in different departments and at different levels have different, often competing priorities.
Moreover, employees tend to make decisions leaning on their own assumptions as to how IT should be used by the organization. IT decisions, guided by foundational beliefs that differ, lack cohesiveness in achieving enterprise goals and require an increased IT governance effort to achieve policy compliance and realize desired business outcomes.
Impact and Result
EA principles succinctly communicate the organization’s intent as to the use of IT in building, transforming, and operating the enterprise and provide a foundation of shared beliefs that guide IT decision making across the organization.
EA principles represent a key component of IT governance and should guide the development of domain-specific policies (e.g. security policy, procurement policy) that elaborate on particular implications of principles in specific process areas.
I believe in developing enterprise architecture principles as a foundation for the definition of solutions that meet the strategic needs of an organization. These principles don’t reference technology—instead, they drive tech- nology decisions.
If used correctly, these principles allow companies to avoid building the right solution the wrong way, or worse, building the wrong solution the right way.
The focus of this article is not the Design Principles of the Architecture but the Principles that guide Enterprise Architects.
These are principles that I shared with the Enterprise Architecture teams I led
Your Challenge:
Situation
Enterprise Architecture increases the organization’s ability to provide consistent services, accessible information, scalable infrastructure, and flexible technology integration on demand. It helps bridge the gap between business and IT and creates a shared enterprise vision.
Complication
EA programs that are run without the required EA capability level are prone to failure.
EA capability optimization and EA operating model design skills are not common, as they are not everyday tasks.
Our Advice:
Critical Insight
Using this research while assessing and optimizing your EA capability will help you:
Architect the EA capability by applying four architectural perspectives: Contextual, Conceptual, Logical, and Physical. Develop an EA Operating Model starting at the contextual level, and proceeding through to the physical.
Develop a sponsored mandate for EA capability. Identify and engage EA capability stakeholders. Determine organizational scope, i.e. responsibility and authority of EA. Identify business drivers for optimizing an EA capability. Analyze organizational context. Secure executive support and authorization to execute.
Establish EA capability purpose and strategic direction. Write EA capability vision statement. Craft EA capability mission statement. Define EA capability goals and measures. Create EA principles. Assess current and determine target EA capability level.
Document EA management process. Define EA management practices. Define interactions between EA management and other processes. Define EA capability performance and value measurement approach.
Design EA organization and roles. Design EA organization structure. Define EA roles. Define required skills and proficiency levels for EA roles. Determine required EA staff capacity.
Standardize EA tools and work products. Establish an EA repository. Decide on EA tools to be used. Define EA artifacts and work products.
Develop an EA capability improvement plan. Consolidate and refine steps required to roll out the target EA operating model and improve EA capability. Draw an EA capability improvement roadmap.
The challenge of alignment, integration and change in the development of e-services has gave attention to enterprise architecture. It provide the framework of engagement and thinking tool to define, elaborate, document, agree and communicate the strategic baseline, strategic intent, strategic architecture, strategic change and strategic resources in the development and improvement of e-services within the defined context and perspectives of time, stakeholders, performance, funds, environment, leadership and technology. The shared open presentation is a product of direct engagement with people of decision and work who are enabled to participate the formulation of enterprise architecture that matters to their performance.
Introduction to Enterprise ArchitectureMohammed Omar
what is Enterprise Architecture
Enterprise Architecture Life-cycle
Enterprise Architecture benefits
Enterprise Architecture challenges
EA driven approach for IT strategy
Enterprise Architecture frameworks
Why do we Need Enterprise Architecture
Lecture 2: The Concept of Enterprise Architecture. The full teaching pack with 19 lectures, tests and other materials based on the book "The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment", which can be freely used for teaching purposes, adapted or translated with references to the original, is available on request to the author (visit http://kotusev.com)
This article describes 10 Architecture Solution Design principles to help organization focus their solution architecture teams around simple but effective design criteria.
Lesen Sie hier die aktuelle Studie der CRIMSON Consulting Group zum Thema "Oracle SOA vs. IBM SOA" . Einschätzung der Komplexität und des Mehrwerts aus Kundensicht.
No SOA ROI - SOA is Dead? Getting SOA ValueAkiva Marks
This historical presentation, circa 2009, describes issues in moving and understanding SOA architecture, and moving from tactical 'just connect it together' towards an enterprise strategy for Service Oriented Architecture and a 'build it once' approach - and how many are struggling with moving from a connect-it to an 'oh no - integration spaghetti'. Did SOA die by 2009? (answer - no, it just became part of the underlying structure.)
I'm presenting the IBM CIO 2010 Outlook at IBM iForum, Zurich (26th November 2007). I can't take the credit for writing it; Dave Newbold did the hard work on this one.
Process integration plays critical role for enterprise business to establish mature process oriented organization. Establishing process oriented organization requires mature process collaboration between systems. Aspire SOA Reference Architecture (ASRA) and the framework helps to establish process integration seamlessly. This presentation reveal that.
Executive Overview Using Soa To Improve Operational Efficiencysean.mcclowry
Overview on how services oriented architectures can be applied to improve operational efficiency. Introduced in the context of the MIKE2.0 Methodology.
2. Contents Architecture & Engineering: Six Principles Solutions need to be architected and engineered prior to being developed/programmed True Object-Oriented Design (OOD) with its industrially-proven good practices Service Oriented Architecture (SOA) Data Centricity Process Centricity Enterprise Taxonomy Legacy
3. Principle 1:Solutions needs to be architected and engineered prior to being developed/programmed Problem: Too many half-literate buzzword-users claiming to be architects (and being delusional enough to believe it!) Diluted difference between programmer, developer, and engineer Result: Solutions not architected and not engineered. Consequently: Within several years, solutions end up on “life support” (extremely costly to maintain and make changes) and soon – completely unusable Solution: Architecture and engineering should become part of IT culture Employ a staff of architects, empower them and measure their performance by the performance of their solutions (don’t get a hollow buzzword-user in place of an architect!).
4. Principle 2:True Object-Oriented Design (OOD) with its industrially-proven good practices It’s not enough to standardize on platforms and versions. Need to also standardize on the way platforms are used: architecture, engineering, development, programming OOD is very significant because it enables (and lack of it makes impossible) software modularity and SOA compatibility: Path: Objects –> Components –> Framework A component is a meaningful collection of objects
5. Principle 3:Service Oriented Architecture (SOA) SOA has many interpretations, definitions and meanings The worst interpretation of SOA is making it synonymous to Web Services. Web Services and XML have solved many heterogeneous integration problems; however, SOA is useful when it reaches throughout the enterprise and encompasses not just low-level infrastructural components but also complex business rules, transactions and processes SOA, if done right, must: Be highly process-centric. In fact, SOA should be deployed in an organic conjunction with BPMS Promote and require IT-Business collaboration on identification and designs of transactional bundles to be deployed as Components and Services The ultimate outcome of a SOA initiative should be a complete model of the organization’s supply chain (all mission-critical processes [components and transactions]) via loosely-coupled, reusable Components and Services.
6. Principle 4:Data Centricity Data is one of the most important asset of an enterprise. Therefore,- Procedurally, Data and Information Management should be a devoted discipline with specifically-identified responsibilities and accountability Data Management Committee Architecturally, The acceptability of any IT solution must be judged based on its ability to support data mining, searcheablity/retrievability, maintainability, portability, interoperability, security, and integrity Looking beyond user interface and examining how data is handled
7. Principle 5:Process Centricity Everything an organization does involves a process; the Supply Chain is a collection of business processes Processes must be mapped, automated and continuously performance-measured A SOA-BPMS environment should be utilized for the automation Business analytics (based on feedback of respective SMEs) should be derived and embedded into the electronic workflow of automated business processes Benefits: Easy to gather scientific evidence of business process performance, and simulate improvement scenarios Easy to monitor business activity and employ contextual event-listeners
8. Principle 6:Enterprise Taxonomy A practical, convention-based categorical/sub-categorical relationship of the organization’s business functions. Example: Function X Sub-function X1 Sub-sub-function X2 Sub-sub-function X…n (location, corporate role, domain of expertise, domain of interest, applications & roles, web content, business processes and SOA components, BI reports & dashboards, customers etc. – the more taxonomical attributes the more complete personalized-customized Web 2.0 experience) Function Y A functional “spinal cord” of the organization Removes boundaries between- and enables a full-fledge implementation of enterprise’s vital taxonomy-dependent initiatives, such as Portal, BI, SOA, Content Management, Document Management, Project Management, Portfolio Management etc.
9. Legacy Revamp vs. Replace decision A short-term retirement vs. long-term retirement If “Revamp”, modularize and improve/optimize within current paradigm If/When “Replace”, recreate application’s functionality via loosely-coupled Components and Services from SOA stack (ideally, legacy apps should be retired when/if its important functionality can be executed via SOA components) Don’t create new legacy by not architecting new solutions the SOA way
