Enterprise Architecture
12.6K views | +1 today
Follow
 
Scooped by Emeric Nectoux
onto Enterprise Architecture
Scoop.it!

TOGAF® 9.1

TOGAF® 9.1 | Enterprise Architecture | Scoop.it

TOGAF 9.1 standard on your smart phone or tablet


via @theopengroup

Emeric Nectoux's insight:

Instead of carrying the complete book, here is the tablet edition.  Smart :)

more...
No comment yet.
Enterprise Architecture
My shared EA's Library Of Knowledge. The most stunning articles related to the whole-of-the-enterprise architecture. Dig and you make up your own mind!
Curated by Emeric Nectoux
Your new post is loading...
Your new post is loading...
Scooped by Emeric Nectoux
Scoop.it!

How to Think Like an Enterprise Architect? ~ Future of CIO

How to Think Like an Enterprise Architect? ~ Future of CIO | Enterprise Architecture | Scoop.it
Enterprise Architecture is the discipline not just for Enterprise Architects, it's the thinking process every business leader should master; and it's the discipline every mature organization needs to practice.
Emeric Nectoux's insight:

Enterprise Architecture is the discipline not just for Enterprise Architects, it's the thinking process every business leader should master; and it's the discipline every mature organization needs to practice.  

 

Not everyone should be an EA, neither everyone wants to be an EA,  but everyone can learn how to think like architect through: systematic thinking, system thinkingholistic thinking, critical thinking, creative thinking, analytics thinking, synthetic thinking, non-linear thinking, abstract thinking, design thinking, whole-brain thinking, positive thinking, etc...

more...
Jaakko Kuosmanen's curator insight, February 11, 2015 8:38 AM

Arkkitehtuuripäivä 25.3.2015: https://kurssit.wakaru.fi/event/index.php?e_hash=5888001583cffd3cae365ab8b482cbe9&from=scoopit

Daniel Tremblay's curator insight, January 16, 2017 12:00 PM
L'architecture d'entreprise n'est pas réservée qu'aux conseillers en architecture.  Tous peuvent apprendre à penser "Architecture d'entreprise".

Trois caractéristiques requises?
- Ouverture d'esprit, pensées critiques et créatives
- Communicateur
- Créateur de synergie d'équipe
Scooped by Emeric Nectoux
Scoop.it!

L'IA, un puissant moteur d'inégalités ?

La place des algorithmes ne fait que croitre dans notre quotidien, souvent dans le but de nous simplifier la vie, mais des voix s’élèvent pour souligner les risques que présentent des décisions rendues de manière automatisée par des IA pour les populations les plus fragiles, peu armées face aux décisions de ces boîtes noires. Les chercheurs trouveront-ils une parade ?

more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Inside SAP: As Cloud Surpasses License Revenue In 2018, 10 Strategic Insights

Inside SAP: As Cloud Surpasses License Revenue In 2018, 10 Strategic Insights | Enterprise Architecture | Scoop.it
With cloud revenue set to exceed license revenue, SAP and CEO Bill McDermott expect total 2018 revenue to exceed $30 billion by delivering customer-centric innovation via the cloud or the traditional on-premises model, complemented by aggressive moves into AI, Machine Learning, Blockchain and IoT.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Vite, remettre de l’humain dans la tech !

Vite, remettre de l’humain dans la tech ! | Enterprise Architecture | Scoop.it

Alors même que nous ignorons où elles vont nous emmener, de nouveaux paliers sidérants sont franchis chaque jour. Nous nous apprêtons à entrer dans une nouvelle ère technologique, celle où les ordinateurs ont des yeux et prennent des décisions, celle d’un Internet contextuel, où l’informatique spatiale (VR, AR), cognitive et contextuelle (IA), physique (IoT) va modifier notre réalité même.

Ne serait-ce pas le bon moment, pendant qu’il est encore temps, de voir comment replacer l’Homme et le vivre ensemble au centre du jeu ? D’essayer de refonder un nouvel ordre ou pacte social ?

Emeric Nectoux's insight:

Excellent article qui me rappelle le "Digital Humanism Manifesto" de Gartner...C'était en 2015:

  1. Put people at the center
  2. Embrace serendipity
  3. Respect personal space

La technologie doit impérativement rester au service de l'Humain et ça devient urgent!

more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Business Architecture at Raytheon: A Conversation with J. Bryan Lail –

Business Architecture at Raytheon: A Conversation with J. Bryan Lail – | Enterprise Architecture | Scoop.it
A number of new Business Architecture methods are being built into the TOGAF® framework to better allow companies to address value stream and business capability mapping. At The Open Group London event in April, J.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Architecture Principles (Engels) door Danny Greefhorst, Erik Proper (Boek) - Managementboek.nl

Architecture Principles (Engels) door Danny Greefhorst, Erik Proper (Boek) - Managementboek.nl | Enterprise Architecture | Scoop.it
'Architecture Principles (Engels)' door Danny Greefhorst, Erik Proper - Onze prijs: €72,99 - Verwachte levertijd ongeveer 8 werkdagen...
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Logical Data Warehouse (LDW) Design and Barcelona

Logical Data Warehouse (LDW) Design and Barcelona | Enterprise Architecture | Scoop.it

Designing a Logical Data Warehouse (LDW) design, is like Town Planning, not like designing a building. When designing an LDW we are reconciling very different information requirements. We already understand that it is not possible to reconcile these very different criteria using a single server, therefore we need to design a system that is an integration of multiple servers. Those multiple servers typically include a data warehouse, a data lake, data marts, maybe an operational data store, and other specialist data stores and servers. In the past, when designing a central data warehouse, or a data lake, we’ve focused on a single system. With the LDW we are, of necessity, designing an architecture with multiple servers, or processing engines.

more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Hybrid cloud, private cloud, public cloud, multicloud? How to choose

Hybrid cloud, private cloud, public cloud, multicloud? How to choose | Enterprise Architecture | Scoop.it
It used to be cloud or no cloud, now it’s an argument around private, hybrid, public, and multicloud architectures.Don’t make the wrong choice...
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Partner Webcast – Practical use cases of Oracle API Platform Cloud Service | Oracle Partner Hub: ISV Migration Center Team Blog

By: Thanos Terentes Printzios | EMEA A&C Technology Adoption Manager Why do Application Programming Interfaces (API) and API Management matter? What would happen if we woke up tomorrow and APIs didn’t exist? We know they are a part of modern technological development and disruption, but do we really understand the importance of APIs? Without APIs, we’re left with ‘application islands’ – a world of isolated data and applications that can’t communicate with each other. APIs and connectivity are an integral to the way technologies, society and culture has evolved – which is why businesses can’t afford to ignore this ‘digital glue’. Moreover, APIs are a core part of the disruption in Industry and organizations worldwide utilize APIs for digital transformation and business growth, adapting to the disruption. Today, a Business Analyst is in the continuous process of designing, extending and improving APIs, while in continuous collaboration with API developers and consumers. Oracle API Platform Cloud Service is a comprehensive and powerful API management solution. The true power of the product lies in its architectural innovations, enabling enterprises to adopt a modern approach to API management. We want to show you how you can apply policies to APIs, to secure, throttle, route, or log requests sent to them, but also how custom development can be developed and deployed by the developers and implementation team on an API Platform. We want you to discover the challenges of poorly managed APIs and how Oracle API Platform Cloud Service uniquely simplifies, secures, and monetizes your APIs. Innovate quickly in a digital world that is moving faster than ever. Be Practical! With Oracle API Platform Cloud Service, develop APIs in a secure, agile environment, all while keeping an eye on key performance indicators for every aspect of the lifecycle. Agenda: Why APIs matter API policy modelling Analyst and Developer role – new approach. API Management and Oracle API Platform Cloud Service Demonstration Configuring Endpoints Configuring Access to Gateway using different types of validation policies Deploying and Testing your API Monitoring API with usage Summary - Q & A Presenters: Remigiusz Wasilewski - Cloud IMC Consultant - Oracle Partner Hub Innovation & Modernization Center Poland Format This FREE online LIVE eSeminar will be delivered over the Web. Registrations received less than 24 hours prior to start time may not receive confirmation to attend. Date: Thursday, Jan 11th , 10 am CET (9am GMT/11am EET) Make sure to also take a look at our Partner Webcast – Setting up API strategy with Oracle API Platform Cloud Service For any questions please contact us at partner.imc@beehiveonline.oracle.com
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Enterprise Architecture is Not THE Answer – It is Part of the Answer –

Enterprise Architecture is Not THE Answer – It is Part of the Answer – | Enterprise Architecture | Scoop.it
As a matter of practicality, for Enterprise Architecture to be successful, there are many things that have to work out before, in parallel with, and after Enterprise Architecture efforts result in an Enterprise Architecture.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Your First AI Project: Avoid Customer-facing Chatbots

Your First AI Project: Avoid Customer-facing Chatbots | Enterprise Architecture | Scoop.it
InformationWeek.com: News analysis, commentary, and research for business technology professionals.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

10 Steps to Launching your First SAFe Agile Release Train

10 Steps to Launching your First SAFe Agile Release Train | Enterprise Architecture | Scoop.it
So you've been excited about Agile for quite some time. You're even more excited now that you learned about the Scaled Agile Framework (SAFeTM) and how it helps organizations scale and successfully implement complex projects, deliver business value and do it on time and under budget! If you even took a cursory look at SAFe you probably heard of the concept of the Agile Release Train (ART). Just as a train delivers its passengers to a destination within a specific cadence, the ART is the primary mechanism of value delivery to the end customer. It is a self-organizing team of Agile teams, composed of "passengers" from various parts of the organization (Development, Security, DevOps, Enterprise Architecture, etc.) that plans, commits and executes together, and they do this within a specific timebox called a Program Increment (PI). The ART team (50-125 people) is designed to align teams to a common business and technology mission, allowing organizations to respond to marketplace changes faster and deliver value faster. So what does an ART launch typically look like? The steps below outline what a typical ART launch requires and can help get you started. 1) Train SAFe Program Consultants (SPCs) SPCs are change agents who lead the transformation and connect the Scaled Agile Framework to your enterprise. They teach the company's leaders and stakeholders and act as coaches and trainers that lead the Agile Release Trains (ARTs). 2) Train Lean Agile Leaders Lean Agile leaders understand the principles and philosophy of the framework (practices, roles activities, and artifacts) and base decisions on these. They also take on the responsibility to lead and facilitate SAFe adoption within the company and help improve business outcomes. 3) Perform a Value Stream Workshop and Identify your FIRST ART Value Streams are a sequence of steps that optimize the value of delivery to the customer. The purpose of a value stream workshop is to Understand and identify Value streams for your organization Select your first Value Stream Identify your first ART 4) Define/Setup the ART and Teams Best practices for setting up an Agile Release Train: Have a clear, defined "product" Gain Leadership support Establish collaboration Significant challenge or opportunity Agile Teams are formed based on: Features/Components Minimizing dependencies Integration addressed DevOps activities being performed 5) Fill important roles Critical roles include: Release Train Engineer System Architect Product Management Scrum Masters Product Owners Customer 6) Prepare and Refine the Program Backlog Product Managers and other senior managers build a list of features to clearly articulate the vision, which is broken down into stories for the teams. 7) Train the Teams Train teams on SAFe for a common, baseline understanding of the framework and set a date for the launch. 8) Conduct PI Planning and Launch ART All participants meet face to face Teams complete plans, assign work and Plan and commit PI objectives Identify dependencies and disposition risks 9) Execute the Program Increment Key Program events: PI Planning, System Demo (every 2 weeks), Inspect & Adapt workshop Architectural Runway Common Cadence so that teams are synchronized 10) Execute the Innovation and Planning (IP) Iteration The IP Iteration is the final 2-week sprint that accomplishes the following: Absorb estimate variances Build in time for innovation Refining backlog for upcoming PI planning Conduct Inspect & Adapt (I&A) workshop Remember that SAFe is NOT a prescriptive entity, and some of the steps can be adjusted to meet specific organizational needs and objectives. Launching an ART can be challenging, so having experienced team members to guide you through will also ensure that your goals can be met. Contact us to help launch your first Agile Release Train!
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

API Management Design Patterns for Digital Transformation

API Management Design Patterns for Digital Transformation | Enterprise Architecture | Scoop.it
Digital Transformation (DT) has become the buzz word in the tech industry these days. The meaning of DT can be interpreted in different ways at different places. Put simply, it is the digitization of your business assets with the increased use of technology. If that definition is not simple enough, you can think of an example like moving your physical file/folder based documents to computers and making them accessible instantly rather than browsing through thousands of files stacked in your office. In a large enterprise, this will go to the levels where every asset in the business (from people to vehicles to security cameras) becomes a digital asset and instantly reachable as well as authorized. Once you have your assets in a digitized format, it is quintessential to expose that digital information to various systems (internal as well as external) through properly managed interfaces. Application Programming Interfaces (APIs) are the de facto standard for exposing your business functionalities to internal and external consumers. It is evident that your DT story will not be completed without having a proper API management platform in place. Microservices Architecture (MSA) has evolved from being a theory of Martin Fowler’s to a go-to technology to implement REST services for your organization when achieving DT. Most developers in the enterprise are moving towards MSA when writing business logic to implement backend core services. But, in reality, there are so many other systems which are coming about as Commercial Off the Shelf (COTS) offerings which do not fit into the microservices landscape natively. With these basic requirements and unavoidable circumstances within your organization’s IT ecosystem, how are you going to implement an efficient API management strategy? This will be the burning problem in most enterprises and I will be touching upon possible solution patterns to address this problem. API Management for Green Field MSA If your organization is just a startup and you don’t want to use high-cost COTS software in your IT ecosystem, you can start off with a full MSA. These kinds of organizations are called 'green field ecosystems,' where you have complete control over what needs to be developed and how those services are going to be developed. Once you have your backend core services written as microservices, you can decide whether or not to expose them as APIs through a proper API management platform. Pattern 1 - Central API Manager to Manage All Your Microservices As depicted in the below figure, this design pattern can be applied to a green field MSA where microservice discovery, authentication, and management can be delegated to the central API management layer. There is a message broker for asynchronous inter-service communication. Figure 1: Central API management in a green field MSA Pattern 2 - Service Mesh Pattern With Sidecar (Micro Gateway) This pattern also applies to a green field MSA where all the backend systems are implemented as microservices. But this pattern can also be applied to scenarios where you have both microservices as well as monolithic (COTS) applications with slight modifications. Figure 2: API management with service mesh and side car (micro gateway) API Management for Practical Enterprise Architecture As mentioned at the beginning of this post, most of the real world enterprises use COTS software as well as various cloud services to fulfill their day-to-day business requirements. In such an environment, if you are implementing an MSA, you need to accept that existing systems are there to stay for a long time and MSA should be able to live along with those systems. Pattern 3: API Management for Modern Hybrid Ecosystem This design pattern is mostly suited for enterprises which have COTS systems as well as an MSA. This pattern is easy to implement and has been identified as the common pattern to apply to a hybrid microservices ecosystem. Figure 3: API management for modern enterprise The same pattern can be applied to any enterprise which does not have any microservices but only traditional monolithic applications as backend services. In such scenarios, microservices will be replaced by monolithic web applications.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Exploiter la donnée, mais pour quoi faire ?

Exploiter la donnée, mais pour quoi faire ? | Enterprise Architecture | Scoop.it

Nombreux sont ceux qui affirment, comme s'il s'agissait d'un dogme, qu'il faut exploiter la donnée. Oui, mais laquelle ? Et, surtout, comment et pourquoi ? Il ne suffit pas de monter une cellule Big Data, de créer un Data Lake ou de travailler sur quelques cas d'usage pour devenir une entreprise « data-driven ». Si, technologiquement, tout est désormais possible, exploiter le plein potentiel de la donnée nécessite de faire le lien avec la stratégie d'entreprise et les objectifs business. Force est de constater que, pour la plupart des grands groupes, ce challenge est loin d'être relevé !

more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Des robots testés à la place des juges dans les cours d'appel de Rennes et Douai

Des robots testés à la place des juges dans les cours d'appel de Rennes et Douai | Enterprise Architecture | Scoop.it

Les premiers tests menés à Rennes et Douai grâce à un logiciel de justice prédictive ne sont pas concluants.

Emeric Nectoux's insight:

Première expérience qui montre que les algorithmes sont perfectibles et surtout que l'homme doit resté maître de la décision finale. 

more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Enterprise Architecture in Mergers and Acquisitions

Enterprise Architecture in Mergers and Acquisitions | Enterprise Architecture | Scoop.it
Mergers and Acquisitions perplex even the most skilled consultant. The opportunities envisioned in initial merger and acquisition pitches are often challenged by the differences that exist between each company. A review of each company’s enterprise architecture provides a useful view into each company’s business model, capacity, resources, and commitment. Strategies that work within one corporate culture may not work in another. This is increasingly true as tools are adapted to fit each unique situation. The era of the benchmark is over as companies modify the tools and strategies of the past; occasionally leveraging tools in contexts they were not originally built for. Instead of creating additional value an attempt to leverage mergers and acquisitions will often compound individual performance issues. Understanding how another company is currently performing is crucial. Evaluating goal and mission alignment with existing technologies used can generate significant insight into capacity, assets, and commitment. M&A Goals Mergers and acquisitions are pursued for different reasons. The attached graph provides an oversimplified introduction to this list as well as attempts to provide a heuristic for evaluating opportunities based on Maslow’s Hierarchy (Level 2 factors) and Herzberg’s Hygiene (Level 1) Factors. The former provides an opportunity for additional value that can generate increase stakeholder performance, satisfaction, and retention; whereas the latter is necessary to even get invited to compete in an industry. The bottom two scenarios are included in this latter category since change leadership and innovation is no longer considered a competitive advantage but is required in order to remain relevant within an ever changing landscape. Merger/Acquisition-to-Objective Business Model Fit Whatever the reason the merger/acquisition-to-objective fit must be evaluated carefully. This begins with the question “does the merger or acquisition drive more value for your business customers?” International Mergers & Acquisitions International engagement impacts each of the factors mentioned above but particularly business culture (Bc) and capacity for change (Cc). Keep in mind that culture and capacity to change often represents a continuum where experience or perspective from one end is reciprocated in the reverse from the other end. For example, what can be too assertive from one end can be reciprocated from the other end with the perception of the other company culture being perceived as to ambivalent (or passive). This Vs.                                                           That Too Assertive Too Lenient Too Reckless Too Cautious Too Structured Too Loose Too Authoritarian Too Laxidasical Too Touchy Feely Too Out of Touch Too Biased Too Impersonal   The challenge is to bridge these gaps. Unfortunately it is more common to apply one’s views without taking into consideration opposing perspectives. Until the gap and a multi-vector perspective are considered, the likelihood of creating shared goals, strategies, processes, or priorities is minimal. Are either company willing to ‘unlearn’ the practices, strategies, and assumptions that reinforce and maintain these gaps? This directly impacts the interconnectivity of processes, systems, and technologies and similarly influences the company’s business model, product/service offerings, and how opportunities are evaluated and pursued. This can particularly be viewed in business models that are dependent on overtly homogenous or narrow support factors, processes, and/or technologies. Performance is constrained as a result, often handing the competitive advantage to competing companies. Enterprise Architectures (EA) and the Business Model Support System The value available through creating a strategic integration plan for each of the above architectures cannot be understated. Neither can the risk of mismanaging these connections. Despite these risks misalignment is all too common. Attempts to manage the inter-dependencies piecemeal need to be avoided. This is particularly evident in mergers and acquisitions (as well as in complex distributed organizations). Strategic efforts to support a merger and acquisition begin with value and culture alignment but end (and must emphasize) the alignment of the business model. The following model describes the Enterprise Architecture Development Method (ADM) proposed in the TOGAF model. This process model is iterative and builds upon previous steps but not require each and every step is developed each time. The process begins with identifying what steps are already addressed following by engaging each stakeholder in the system to develop out the following step and components. As most examples of failed mergers and acquisitions have proven a sh ared vision and values is not enough to guarantee success. Unless each company is to operate separately shared enterprise architecture is required to leverage similar processes, systems, and structures across the business model. This is accomplished by an interlocking, shared, and interdependent business architecture, information systems architecture, application architecture, and technology architecture. Early technology questions will vary on the industry and goals of the M&A but will often emphasize the following: What goals currently exist? What technologies are deployed to support these goals? Are the goals and technology matched? If not, why? What are the consequences? Companies with competing components will resist efforts to support and sustain future alignment. Although some companies may choose to still pursue the merger and acquisition, due to the anticipation of benefits (or the avoidance of current business risks), technology integration represents a useful way to evaluate: Past performance Future goals Alignment with technology and process assets Capacity, and commitment, to delivery performance KPI’s The next step involves confirming the requirements to be supported by the enterprise architecture; designing and executing the processes, strategies, and tools necessary to develop the structures, architecture, and systems; and launching the product, and support mechanisms, into the environment.  Inputs Processes Outputs Real time information Committee Mobile App Confidential Working Groups Desktop Application Analytic ability Build out architecture Web based app/cloud Easy access Integration of systems Backup data to cloud Mobile Migration of Data Authors Secure Test MVP Access authority levels Cross system collaboration Feedback Component owners Alerts Updates Communications Goals Maintenance Planning Training Progress Reporting Stakeholder Consults Maint. & Upgrades   Technology architecture and process misalignment, within or across companies, can undermine future performance. Taking an honest look at the compatibility of each company’s technology and process assets with the other company can be a significant first step towards identifying best transition practices moving forward. Leveraging Interlocking Structures One way to both evaluate AND build merger/acquisition-to-objective fit is to review the enterprise architecture supporting both companies: Will they work well together? Do they perform similar objectives? Can lessons in one company (area) be shared and used in the other company? The Enterprise Architecture Body of Knowledge (EABOK) also suggests the following questions for building out a shared architecture: Develop those areas where you plan to make investments. Develop them to sufficient level of detail that you can see the new projects you Develop areas where you are experiencing difficulties such as performance problems or coordination problems. Develop nontrivial areas where there is high turnover and constant Develop areas where you will have significant interaction with other organizations and the interface needs to be well defined. Answering these questions is no easy task and often emphasizes both qualitative and quantitative key performance indicators (KPI’s) as well as values, assumptions, and strategic priorities. Unfortunately most evaluations remain subjective and focus more on optimistic thinking, or financial measures, more than an evaluation of whether the two companies can work in (relatively) perfect alignment. A standardized approach that emphasizes more than just strategic numbers is needed. Enterprise Architectures (EA) The enterprise architecture is a conceptual blueprint that defines the structure and operation of an organization. The intent of enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives (SearchCIO.com). The enterprise architecture supports the company’s: Business Architecture (BA): Business processes, organization, people Application Architecture (AA): Services Data Architecture (DA): Data, information Technology Architecture (TA): Hardware, software, network   Evaluating Company Readiness Evaluating your company’s merger and/or acquisition opportunity begins with a SWOT analysis of each company’s performance, key performance indicators, financial metrics, and existing enterprise architectures. The technical systems and resources support the company’s ability to integrate new assets whereas the qualitative competencies and processes support each company’s ability to facilitate and sustain the transition. Both the technical systems and qualitative competencies are crucial and rely on one another but without the availability of compatible interlocking components the transition process will often progress at cross purposes. Reviewing the enterprise architecture of both companies allows the leadership teams to determine company compatibilities (or areas of incompatibility), what M&A risks exist, the likelihood of achieving M&A objectives, and whether or not the M&A would represent a ‘step forward’ or ‘backwards.’ Statistical Evaluation of Qualitative M&A Factors A definition of business model fit must take into consideration both qualitative and quantitative components. An elementary algebraic formulation can be used to evaluate company-to-company fit using the factors discussed earlier. Fit thus represents a conceptual business model construct that aligns two (or more) geographically distributed corporations across key structural, process, and technological areas. Fit can be achieved through efforts to: Build ‘from scratch’ Connect pre-existing mutually compatible components Leverage existing compatibility to strengthen deficient areas The above graph depicts a theoretical ranking distribution for BMTechFit. Statistical Evaluation of Qualitative and Quantitative M&A Factors Homeostatic mechanisms will dominate the process unless structural, process, and architectural compatibility exists. With increased compatibility the challenge of sustaining benefits of the merger or acquisition becomes easier. Evaluating how the business model and the enterprise architecture of both companies interconnect (and identifying if integration will be successful) can now use a more complex formula based on the above sections: Most merger and acquisition failures fall into scenario #3, leaving scenarios #1 & #2 as opportunities to increase the chances for success. Moving beyond traditional value or KPI based assessments to an evaluation of each company’s business model and supporting enterprise architecture (Fit) can be a useful route towards evaluating the likelihood of M&A goals being realized. A Case Example An evaluation of the network’s enterprise architecture fit for the four companies listed above is included below. Steps Ranking (1 to 5) Benefits Status Step 1: Architecture Vision 3 Avoids re-inventing the wheel Different architectural visions are evident throughout the network. The results are as follows. Step 2: Business Architecture 3 Business IT alignment Business architecture meets minima standards but provides limited support to planning, evaluation, and risk management. Accessibility to primary systems and assets is limited. Step 3: Information Systems Architectures 3 Based on best practices Fragmented systems. Different systems used for each member. History of failed centralization, costing millions. Step 4: Technology Architecture 2 Possible to participate in the evolution of the framework Stakeholders often feel left out of the planning discussions. Upgrades are subsequently resisted. Step 5: Opportunities & Solutions 2 Available under a free perpetual license Fragmentation limits standardization and sharing of best practices/technologies. No central repository exists. Researching standards and best practices, internally, is resisted as this can result in ‘intervention’ or ‘interference.’ Step 6: Migration Planning 2 Tailorable to meet an organization and industry needs Technological lags are not often acknowledged, which interferes with substantive (vs. vanity or surface) innovations that solve core/root problems. Step 7: Implementation Governance 3 Widely adopted in the market Fragmented, limiting systems thinking, organizational learning, network planning, etc. Step 8: Architecture Change Management 2 Complementary to, not competing with, other frameworks Fragmentation (see above) creates pockets of resistance and limits information sharing, evaluation, problem solving, and strategy execution across network nodes. 20   Company A’s oversight responsibilities has resulted in continued top-down efforts to centralize governance, reinforce accountability, and drive performance. Due to the fragmentation a full merger with the other companies in the network has not been attempted. The reasons are numerous, but will not be explained in further detail here. Each company operates with relative independence. Company A’ and member organizations are increasingly introducing a portfolio management approach to network governance based on each company’s expertise. The early results are disappointing but the final numbers have yet to be tallied. Business Model Technology Fit Evaluation and Planning Tool (BMTechFit) The merger and acquisition evaluation checklist is adapted to TOGAF’ enterprise architecture development model (ADM). Each step is interdependent with the larger planning process. Although each company will probably not need to cover every step it is useful to review all of these steps at least once each planning cycle AND when considering a merger or acquisition. A planning tool is provided below emphasizing the evaluation of the company’s combined enterprise architecture fit. Business Model Technology Fit Evaluation Steps Benefits Status (criterion) Action Plan Step 1: Architecture Vision Avoids re-inventing the wheel   Does a shared vision exist? Step 2: Business Architecture Business IT alignment What technologies, processes, and tools are needed to support the business model? Mission? Values? Goals?   Do the existing technologies work together or at cross purposes? Step 3: Information Systems Architectures Based on best practices Is the information needed available? Does it support iterative learning and the goals intended? Is it freely available and accessible to all who need it? Step 4: Technology Architecture Possible to participate in the evolution of the framework Is the current iteration aligned with future directions for the company’s technology? Is there agreement regarding what technology is needed to deliver future requirements? Step 5: Opportunities & Solutions Available under a free perpetual license Are technology standards available to build out future solutions? Are these matched with training and technical resources to deliver across the enterprise? Step 6: Migration Planning Tailorable to meet an organization and industry needs  Is a migration plan in place when the technology needs an upgrade OR replaced? What teams are involved? What resources will be needed? Step 7: Implementation Governance Widely adopted in the market  How is the technology managed and maintained? Who? When? Evaluated? Who makes decisions? Step 8: Architecture Change Management Complementary to, not competing with, other frameworks  What is the criterion for identifying technology expiration? For evaluating technology-to-objective fit deterioration? Who takes the lead? What tools and models are suggested to facilitate the transition? Who approves the change(s)?   In principle, each component (step) can be evaluated on a scale of 1-5 with the totals being added across all 8 components. The highest possible score for evaluating MAfit is = 40. A score below 32 should probably be evaluated very closely to determine if any previously unforeseen risks may exist that could jeopardize company integration. Conclusions The challenges facing a merger are arguably greater than a simple acquisition. The former requires compatibility at the architectural, process, business model, and social levels. The latter only requires acquisition with considerable flexibility remaining regarding the structure of the company’s relationships within the (owned) network. The models, and formulations discussed above, can be used to evaluate both private and public sector networks although the latter is often given greater latitude for inefficiencies. This doesn’t have to be the case as both sectors can be evaluated based on their business model and enterprise architecture fit. Misalignment can be very costly regardless the industry sector and needs to be taken quite seriously if the pitfalls of a poorly planned merger or acquisition is to be supported. With NGO’s we often find a lag in technology and KPI adoption, which warrants cautious selection of tools to increase service line support, evaluation, and delivery. Yet there is also a balance when a lack ‘of’ a technical foundation is met with performance issues. Moving from this stage with technical competencies, which are often experienced as impersonal and alienating, can be challenging. In some of these cases the companies may benefit beginning with a dialogue around: Benchmarks Goals Gaps Process maps/ service standards Vision, and then………. The tools that help teams to drive performance Collaborating across organizations can also be helpful to create engagement, vision, and hope. NGO’s can also (essentially) lack a coherent structure; when this occurs the culture can resist standardization. How is your company evaluating M&A fit? Share your comments below.   Travis Barker, MPA GCPM Innovate Vancouver [email protected]   Resource: EABOK Consortium . (n.d.). EABOK. Retrieved February 03, 2018, from http://eabok.org/eabok.html Togaf 9.1 can be found at opengroup.org   TAGS: BUSINESSBUSINESS ARCHITECTURECHANGE MANAGEMENTCONSULTINGGAP ANALYSISKEY PERFORMANCE INDICATORSLEADERSHIPSYSTEM'S THINKING
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Ten red flags signaling your analytics program will fail | McKinsey & Company

Ten red flags signaling your analytics program will fail | McKinsey & Company | Enterprise Architecture | Scoop.it
Struggling to become analytics-driven? One or more of these issues is likely what’s holding your organization back.
  1. The executive team doesn’t have a clear vision for its advanced-analytics programs
  2. No one has determined the value that the initial use cases can deliver in the first year
  3. There’s no analytics strategy beyond a few use cases
  4. Analytics roles—present and future—are poorly defined
  5. The organization lacks analytics translators
  6. Analytics capabilities are isolated from the business, resulting in an ineffective analytics organization structure
  7. Costly data-cleansing efforts are started en masse
  8. Analytics platforms aren’t built to purpose
  9. Nobody knows the quantitative impact that analytics is providing
  10. No one is hyperfocused on identifying potential ethical, social, and regulatory implications of analytics initiatives
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Enterprise Ethereum Architecture Stack Launched

Enterprise Ethereum Architecture Stack Launched | Enterprise Architecture | Scoop.it
The world’s biggest blockchain consortium, Enterprise Ethereum Alliance (EEA), has just announced they have launched the first Enterprise Ethereum Architecture Stack. They say: “This stack defines the building blocks needed to...
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

The Importance of Enterprise Architecture for Business Transformation: Lessons Learned –

The Importance of Enterprise Architecture for Business Transformation: Lessons Learned – | Enterprise Architecture | Scoop.it
In a 2016 blog for The Open Group, we described what really happens when IT is run like a business based upon our recent work at SKF, where we work as Enterprise Architects and IT Strategists.We explained how we became confident to transform the way IT worked with the business to provide value, and…...
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Top 5 Big Data Integration Challenges - Be Prepared!

Top 5 Big Data Integration Challenges - Be Prepared! | Enterprise Architecture | Scoop.it
Big data integration challenges include getting data into the big data platform, scalability problems, talent shortage, uncertainty, and synchronizing data.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Enterprise DevOps: On Governance - DZone DevOps

Enterprise DevOps: On Governance - DZone DevOps | Enterprise Architecture | Scoop.it
This is the fifth in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner, and Sacha Labourey, CEO, CloudBees. In a previous article we discussed creating a standard taxonomy and from there defining your technology stack. This is an important first step; however, it is also critical that you define a process to govern requests for changes to this stack. It is a given that in the world of technology there is rapid change. It is also a given that the rate of change will only increase in the future. A technology stack that ossifies will lead to significant difficulties and lost opportunities. By the same token, an uncontrolled proliferation of solutions will lead to greater financial cost, a likely divergence in process and potentially a loss of the feedback and process control that is critical to successful DevOps. If your organization is heavily regulated, it could also lead to a reduction in auditability and the incumbent risks associated with this. It is thus critical that a process is created to enable and govern change. This may already be in place in your organization, but in our experience, once an organization starts to adopt a DevOps mindset, the rate of request for change increases and the cadence of governance decisions needs to be able to respond to this. A further consideration is that DevOps relies on practitioner empowerment. Many extant governance processes rely on central command control and this is anathema to the culture we are looking to inculcate in the organization. Below we detail a range of considerations and a potential approach to governance. Within a governance board, we believe the following considerations should be represented. Governance chair: Chairs the meeting, ensures minutes are taken and discussions are documented. Is accountable for maintaining the core principles that requests are judged against. Includes any change to the core principles. Practitioner representative(s): Presents the request(s) and represents their community. Enterprise architecture representative: Owns the Enterprise Information Management (EIM) and acts as design authority for technology within the organization. Service line representative: Owns the provisioning of services for those capabilities which are deemed to be centrally provisioned. Infrastructure representative: Represents that part of the organization accountable for centralized infrastructure provisioning. Even in an organization that has fully adopted cloud, somebody will be accountable for that relationship and provisioning. Procurement representative: It is likely you have a vendor strategy. This needs to be represented. Assists with RFP considerations if the proposed change looks to have potential to benefit the organization. You may have commercial arrangements with one vendor that are pertinent in the capability space. Larger organizations may have actually invested in a vendor (such as the automotive industry). Security representative: Represents security considerations and ensures security is engaged at the earliest possible stage. Financial representative: Represents whoever owns the overall budget and signs the check. Please note in a large organization each consideration may be represented by a different individual. In smaller organizations, an individual may represent more than one consideration. At startup, having awareness of these considerations will assist in ensuring you create a robust and scalable process even if a single individual is involved in making the decisions. Suggested governance board outputs: This request is in line with our principles and should be centrally provisioned This request is in line with our principles and should be locally provisioned This request is not in line with our principles, our principles should change. This request is not in line with our principles and is rejected. Hopefully, this decision list is self-explanatory. In our view, a key consideration is decision point three. It is important that you consistently question whether your principles are correct and leave the opportunity to amend these in line with changes in circumstance and objectives. In our experience, this also stresses to the practitioners that they have a measure of control in the governance process and this helps to drive engagement and the collaborative culture that DevOps thrives upon. The last point we wish to stress is that while all these considerations are material, any governance model has to be fit for the purpose of making robust and rational decisions rapidly. Governance is a means to an end, not an end in itself. You should constantly validate that you are not building bureaucracy and waste into this process, as boards and processes tend to mutate and bloat over time if not consistently challenged. Follow the series from Sacha and Nigel Enterprise DevOps: An Introduction Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point Enterprise DevOps: Context is King Enterprise DevOps: Creating a Service Line Enterprise DevOps: On Governance (this post)
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Enterprise Artificial Intelligence Architecture | Enterprise Architecture at Oracle

Enterprise Artificial Intelligence Architecture | Enterprise Architecture at Oracle | Enterprise Architecture | Scoop.it
Enterprise Artificial Intelligence Architecture
If you think back to Greek mythology, an Oracle was a person who
provides wise counsel, prophetic predictions, or...
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

What is Data Architecture?

What is Data Architecture? | Enterprise Architecture | Scoop.it
Data Architecture “includes specifications used to describe existing state, define data requirements, guide data integration, and control data assets as put forth in a data strategy.” Data Architecture bridges business strategy and technical execution, and according the recent Trends in Data Architecture Report: “Data Architecture is as much a business decision as it is a technical one, as new business models and entirely new ways of working are driven by data and information.” According to the DAMA International Data Management Book of Knowledge, Data Architecture can be synthesized into the following components: Data Architecture Outcomes: Models, definitions and data flows on various levels, usually referred as Data Architecture artifacts Data Architecture Activities: Forms, deploys and fulfills Data Architecture intentions Data Architecture Behaviors: Collaborations, mindsets and skills among the various roles that affect the enterprise’s Data Architecture Other Definitions of Data Architecture Include: “Common vocabulary expressing integrated requirements ensuring that data assets are stored, arranged, managed, and used in systems in support of an organizational strategy.” (Dr. Peter Aiken) “A set of rules, policies, and models that determine what kind of data gets collected, and how it gets used, processed and stored within a database system.” (Keith Foote, DATAVERSITY®) “Using data effectively and built on a foundation of business requirements.” (Sven Blumberg, et. Al., McKinsey) “Describes how data is collected, stored, transformed, distributed and consumed. IT includes rules governing structured formats, such as databases and file systems, and the systems for connecting data with the business process that consume it.” (DalleMule and Davenport, Harvard Business Review) “Models, policies, rules, or standards that govern which data is collected, and how it is stored, arranged and put to use in a database system and or in an organization.” (Business Dictionary) Visual Example of Data Architecture Elements: Image Credit: Max Griboedov/Shutterstock.com   Businesses Use Data Architecture to: Strategically prepare organizations to quickly evolve and to take advantage of business opportunities inherent in emerging technologies Translate business needs into data and system requirements Facilitate Alignment of IT and business systems Manage complex data and information delivery throughout the enterprise Acts as agents for change transformation and agility “Depict the flow of information between people (users) and Business Processes”   Photo Credit: NicoElNino/Shutterstock.com
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Reference architecture for enterprise reporting in Azure

Reference architecture for enterprise reporting in Azure | Enterprise Architecture | Scoop.it
Details on a technical reference implementation of an enterprise grade infrastructure to help accelerate the deployment of a BI and reporting solution.
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Under the Hood: Demystifying Docker Enterprise Edition 2.0 Architecture – Collabnix

Under the Hood: Demystifying Docker Enterprise Edition 2.0 Architecture – Collabnix | Enterprise Architecture | Scoop.it
The Only Kubernetes Solution for Multi-Linux, Multi-OS and Multi-Cloud Deployments is right here… Docker Enterprise Edition(EE) 2.0 Final GA release is available. One of the most promising feature announced with this release includes Kubernetes integration as an optional orchestration solution, running side-by-side with Docker Swarm. Not only this, this release includes Swarm Layer 7 routing improvements, Registry image mirroring, Kubernetes integration to Docker Trusted Registry & Kubernetes integration to Docker EE access controls. With this new release, organizations will be able to deploy applications with either Swarm or fully-conformant Kubernetes while maintaining the consistent developer-to-IT workflow. Docker EE is more than just a container orchestration solution; it is a full lifecycle management solution for the modernization of traditional applications and microservices across a broad set of infrastructure platforms. It is a Containers-as-a-Service(CaaS) platform for IT that manages and secures diverse applications across disparate infrastructure, both on-premises and in the cloud. Docker EE provides an integrated, tested and certified platform for apps running on enterprise Linux or Windows operating systems and Cloud providers. It is tightly integrated to the underlying infrastructure to provide a native, easy to install experience and an optimized Docker environment. Docker EE 2.0 GA consists of 3 major components which together enable a full software supply chain, from image creation, to secure image storage, to secure image deployment. Universal Control Plane 3.0.0 (application and cluster management) – Deploys applications from images, by managing orchestrators, like Kubernetes and Swarm. UCP is designed for high availability (HA). You can join multiple UCP manager nodes to the cluster, and if one manager node fails, another takes its place automatically without impact to the cluster. Docker Trusted Registry 2.5.0 – The production-grade image storage solution from Docker & EE Engine 17.06.2- The commercially supported Docker engine for creating images and running them in Docker containers. Tell me more about Kubernetes Support.. Kubernetes in Docker EE fully supports all Docker EE features, including role-based access control, LDAP/AD integration, scanning, signing enforcement, and security policies. Kubernetes features on Docker EE include: Kubernetes orchestration full feature set CNCF Certified Kubernetes conformance Kubernetes app deployment by using web UI or CLI Compose stack deployment for Swarm and Kubernetes apps Role-based access control for Kubernetes workloads Pod-based autoscaling, to increase and decrease pod count based on CPU usage Blue-Green deployments, for load balancing to different app versions Ingress Controllers with Kubernetes L7 routing Interoperability between Swarm and Kubernetes workloads for networking and storage. But wait.. What type of workload shall I run on K8s and what on Swarm? One of the question raised multiple times in last couple of Docker Meetup was – Good that now we have K8s and Swarm as multi-orchestrator under the single Enterprise Engine. But what type of workload shall I run on Kubernetes and what on Docker Swarm?   As shown above, even though there is a bigger overlap in terms of Microservices, Docker Inc. recommends specific types of workloads for both Swarm and Kubernetes. Kubernetes works really great for large-scale workloads. It is designed to address some of the difficulties that are inherent in managing large-scale containerized environments. Example: blue-green deployments on Cloud Platform, highly resilient infrastructure with zero downtime deployment capabilities, automatic rollback, scaling, and self-healing of containers (which consists of auto-placement, auto-restart, auto-replication , and scaling of containers on the basis of CPU usage). Hence, it can be used in a variety of scenarios, from simple ones like running WordPress instances on Kubernetes, to scaling Jenkins machines, to secure deployments with thousands of nodes. Docker Swarm, on the other hand, do provide most of the functionality which Kubernetes provides today. With notable features like easy & fast to install & configure, quick container deployment and scaling even in very large clusters, high availability through container replication and service redundancy, automated internal load balancing, process scheduling, Automatically configured TLS authentication and container networking, service discovery, routing mesh etc. Docker Swarm is best suited for MTA program – modernizing your traditional legacy application(.Net app running on Windows Server 2016)  by containerization on Docker Enterprise Edition. By doing this, you reduce the total resource requirements to run your application. This increases operational efficiency and allows you to consolidate your infrastructure. Under this blog post, I will deep dive into Docker EE Architecture covering its individual components, how they work together and how the platform manages containers. Let us begin with its architectural diagram –   At the base of the architecture, we have Docker Enterprise Engine. All the nodes in the cluster runs Docker Enterprise Edition as the base engine. Currently the stable release is 17.06 EE. It is a lightweight and powerful containerization technology combined with a work flow for building and containerizing your applications. Sitting on top of the Docker Engine is what we call “Enterprise Edition Stack” where all of these components run as containers(shown below in the picture), except Swarm Mode. Swarm Mode is integrated into Docker Engine and you can turn it on/off based on your choice.Swarm Mode is enabled when Universal Control Plane (UCP) is up & running.   UCP depicting ucp-etcd, ucp-hyperkube & ucp-agent containers In case you’re new to UCP, Docker Universal Control Plane is a solution designed to deploy, manage and scale Dockerized applications and infrastructure. As a Docker native solution, full support for the Docker API ensures seamless transition of your app from development to test to production – no code changes required, support for the Docker tool-set and compatibility with the Docker ecosystem.     From infrastructure clustering and container scheduling with the embedded Docker Swarm Mode, Kubernetes to multi-container application definition with Docker Compose and image management with Trusted Registry, Universal Control Plane simplifies the process of managing infrastructure, deploying, managing applications and monitoring their activity, with a mix of graphical dashboards and Docker command line driven user interface There are 3 orchestrators sitting on top of Docker Enterprise Engine – Docker Swarm Mode, Classic Swarm & Kubernetes. For both Classic Swarm and Kubernetes, there is the same underlying etcd instance which is highly available based on setup you have in your cluster. Docker EE provides access to the full API sets of three popular orchestrators: Kubernetes: Full YAML object support SwarmKit: Service-centric, Compose file version 3 “Classic” Swarm: Container-centric, Compose file version 2 Docker EE proxies the underlying API of each orchestrator, giving you access to all of the capabilities of each orchestrator, along with the benefits of Docker EE, like role-based access control and Docker Content Trust. To manage lifecycle of orchestrator, we have a component called Agents and reconciler which manages both the promotion and demotion flows as well as certification renewal rotation and deal with patching and upgrading. Agent is the core component of UCP and is a globally-scheduled service. When you install UCP on a node, or join a node to a swarm that’s being managed by UCP, the agent service starts running on that node. Once this service is running, it deploys containers with other UCP components, and it ensures they keep running. The UCP components that are deployed on a node depend on whether the node is a manager or a worker. In nutshell, it monitors the node and ensures the right UCP services are running. Another important component is Reconciler. When UCP agent detects that the node is not running the right UCP components, it starts the reconciler container to converge the node to its desired state. It is expected for the UCP reconciler container to remain in an exited state when the node is healthy. In order to integrate with K8s and support authentication, Docker Team built open ID connect provider. In case you’re completely new to OIDC, OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an inter-operable and REST-like manner. As Swarm Mode is designed, we have central certificate authority that manages all the certificates and cryptographic node identity of the cluster. All component uses mutual TLS communication and they are using nodes which are issue by certificate authority. We are using unmodified version of Kubernetes. Sitting on the top of the stack, there is GUI which uses Swarm APIs and Kubernetes APIs. Right next to GUI, we have Docker Trusted Registry which is an enterprise-ready on-premises service for storing, distributing and securing images. It gives enterprises the ability to ensure secure collaboration between developers and sysadmins to build, ship and run applications. Finally we have Docker & Kubernetes CLI capability integrated. Please note that this uses un-modified version of Kubernetes API. Try Free Hosted Trial If you’re interested in a fully conformant Kubernetes environment that is ready for the enterprise,    https://trial.docker.com/ Did you find this blog helpful? Feel free to share your experience. Get in touch with me on Twitter –  @ajeetsraina If you are looking out for contribution, join me at Docker Community Slack Channel. References: 1 0
more...
No comment yet.
Scooped by Emeric Nectoux
Scoop.it!

Digital Transformation at Amsterdam’s Schiphol Airport: A Conversation with Aaldert Hofman –

Digital Transformation at Amsterdam’s Schiphol Airport: A Conversation with Aaldert Hofman – | Enterprise Architecture | Scoop.it
Global air travel is growing at exponential rates. According to the International Air Transport Association (IATA), air travel is expected to double by 2035, growing from 3.8 billion travels in 2016 to 7.2 billion.
more...
No comment yet.