Architecture

Enabling, Migrating and Supporting Hybrid Cloud
Environments in Enterprise Architectures using specific
methods and patterns
• Digital Transformation of business processes these days often are driven by
new technologies enabling new business cases. Sometimes they are driven
by technological evolution
• The use of i.e. BigData technology for automating business processes forces
Enterprise Architecture Management to use specific methods and patterns to
enable the enterprise architecture to support to be scalable , … using hybrid
cloud environments.
Authors:
Consulting Engineer Albrecht Stäbler [email protected]
CTO of digital business company www.dibuco.de Andreas Tönne [email protected]
• Dipl.-Ing. Albrecht Stäbler, Beratender Ingenieur; Consulting Engineer
• [email protected]
• Dipl.-Inform. Andreas Tönne, CTO dibuco (digital business company
www.dibuco.de)
• [email protected]
Why is a traditional approach of planning IT systems unsustainable
• Too many external factors affecting technological competencies
Generation Y
Disruptive
Technology
Changes
Government
Prominent Role
Leadership
Excellence Vision
Need for
Business
Change
Regulation
“Executives need to stop looking at IT projects as
technology installations and start looking at them as
periods of organizational change that they have the
responsibility to manage”
Harvard Business Review, November 2006 by Andrew McAfee, Associate Professor, Harvard Business School
Triggers for migration projects
• Technological evolution, budget driven, cost savings, …
• Cloud enabling
• From IaaS via PaaS to SaaS, mostly private or hybrid cloud
• Triggered by IT and CIO
• Digital transformation of business processes / whole companies
• Cloud native
• Triggered by the business
Digital Transformation Enabling Technology
Now we got all the data BigData evangelists talk about
Help! How can we handle this?
• Data Lake considered harmful
Does anyone know what is INSIDE this data?
• Lack of a-priori knowledge of contents and structure
Gaining Insight in Heterogenous Data
• Middleware solution for semantically structuring all kinds of data
• Relational data is structured through its schema
• iQser GIN lifts this to the level of all data with a „meaning“
• Result: Annotated graph of data objects connected by relationships based on
their content
iQser: Standard Relationship Discovery
• Word matching (aka „the simple way“)
• Concept matching (+ semantical methods)
+ Custom plugins
• Uniform Information Model (the „schema“)
• Enterprise Content Service Bus (business object delivery)
iQser: Use-Cases
• Content delivery to business processes based on process context
• Contextual Search for „interesting“ other data
• Master Data Management
• Mix-in of documents based on commonalities
• Content based comparison
• Partitioning of data (structuring the data lake)
• ....
A Cloud Migration Story
• GIN was migrated from a Java EE old-school architecture to a cloud
architecture
• We delivered consulting for
•
•
•
•
•
Cloud / Big Data architecture transformation
Conceptual transformation of the algorithms to be cloud ready
Lightweight microservice frameworks
Development, testing, performance
Introduction of suiting development processes
• 100% rewrite
• 11 man-year effort, six months time for release #1, in time
Architecture at 1 Feet Distance
• Analysis: SEDA pattern + plugin architecture
• Spring Boot microservices
• Maxed out flexibility
Architecture at 1.000 Feet Distance
Challenges: Business Rules Transformation
• Digital Business Transformation affects business rules
• GIN concepts inhibited scalability very effectively
• Transactional thinking – Computation is serial
• Uniqueness constraints
• Illusion of always accurate global information
• Consistency is the business cake you cannot have and eat at the same time
when going Big Data scale
• If you go from gigabytes to petabytes, you have to accept changes to the rules
Challenges: Architectural Consequences
• Shared-alot Problem
• Relationship discovery seems to mean „compare everything with everything else“
• Semantic knowledge needs to be global across all concurrent services
• Way too much writing going on
• How to avoid deadly congesture at the database level?
• How to scale the analysis pipelines?
• Do we know what is going on?
• Monitoring
• Prediction of graph growth
Transformation Strategies
• Reduce Locking
• Lift some uniqueness constraints
• Prefer horizontal scalability over „quality“
• Allow for eventual consistency
• Split the timeline of semantical analysis
• Almost realtime analysis with possibly stale global knowledge (good enough)
• Hadoop batchjobs periodically refresh accuracy
• Be content with statistical approximations
• We do not need to know exactly the number of occurrences of a word
• Define new algorithms
The Transformation Never Stops
• Adding new cloud services is not enough for new business demands
• If you overcome one brickwall, you know you will run into the next brickwall
soon
• Digital Transformation requires to refactor the architecture periodically
• New business goals, processes
• Growing reach of the solution
• Growing data rates and volume
EAM brings the business and IT strategy in alignment to each other
New business
possibilities
Business
Strategy
(CEO Agenda)
ITStrategy
(CIO Agenda)
New
Technologies
business enabler
•
•
New/Changed processes
New Technologies
Strategy
Costs
(CFO Agenda)
Architecture
Company
Architecture
•
•
•
•
Enabling technological innovation
Containment of IT complexity
Administration Bus. Portfolio
Legislating of order
System
Architecture
•
•
•
Asignment of new technologies
Automation of new processes
Execution of new projects „In Time“ and „In
Budget“
Enterprise Architecture is company architecture considering IT of the whole
company
Role
Company
architecture
System
architecture
Company architect
System architect
Theme
Business
architecture
•
Business process charts
Information system
Architecture
•
Application charts
Technology
Architecture
•
•
Overview BusApp.-platforms
Overview (HW/OS) platforms
Charakteristic
Cf „Architecture“
•
•
•
•
•
Company-wide (big picture)
Constantly
Overview
Total Cost of Ownership
City map
•
•
•
Principles
Guidelines
Modules
•
Automation of particular processes
and sub-processes
•
Architecture of a system
•
New
modules
•
Notice of a platform
•
•
•
•
•
System-wide
Project focus (particular system)
Detail
Total Cost of Acquisition
Seperate house
Enterprise Architecture: Customize TOGAF to Enterprise’s specific needs, and
integrating it with existing Enterprise processes and frameworks. Other domain
specific frameworks will also be evaluated within the Architecture Team
TOGAF Architecture Development Method (ADM) is an iterative methodology which
can be adapted to the specific requirements of a company.
Framework
And
Principles
G.
Implementation
Governance
F.
Migration
Planning
Requirements
Management
E.
Opportunities
and
Solutions
B.
Business
Architecture
C.
Information
Systems
Architecture
D.
Technology
Architecture
Company
Enterprise Continuum
TOGAF + Company
Enterprise Continuum
H.
Architecture
Change
Management
A.
Architecture
Vision
Architecture
Domains
In the implementation of the target architecture intermediate steps can be included
for large projects because of the wide time horizon.
A.
Architecture
Vision
Baseline
Transition
(incrementally)
Transition
(incrementally)
Target
(evolutionary)
...
t0
t1
t2
...
t target
t
The phases of a TOGAF Architecture Development Cycles consist of steps which
create outputs based on inputs.
Objectives
ADC Phase
1. Step
Input
2. Step
6.Step
5.Step
3.Step
4.Step
Approach
Output
Business Layer
Objectives
• Creation of a validated and complete Business
Architecture
• New or refined Service
• Business Drivers
Input
Output
• Architecture Vision
9. Architecture
Definition Document
1. Vision /
8. Complete
Requirements /
Architecture
Uptake Baseline
• Baseline and Target
Business Architecture
• Architecture Principles
• Use of company specific
Architecture Repository
• Common Architectures
7. Stakeholder
Review
2. Identify
reference models,
tools, viewpoints
6. Cross Impact
3. Develop
architecture
descriptions
5. Roadmap
• Business Strategy
• Business Architecture
•
Processes
•
Service
•
Roles
•
Business Data
• Technical Requirements
• GAP-Analysis
4. GAP Analysis
• Baseline analysis Bottom-Up
• Target analysis Top-Down
• Reuse existing information and artifacts
• Development of a complete target vision without
going into detail
Approach
Application Layer
Objectives
• Determination of company relevant applications
and properties
• Architectural overview of the applications
infrastructure and their connections
• Determination of communication between
applications and stakeholders
Input
Output
• Target Business
Architecture (Vision)
• Baseline Information
System Architecture
8. Complete
architecture
7. Stakeholder
Review
1. Vision /
Requirements /
Uptake Baseline
• Architecture Principles
• Use of company specific
Architecture Repository
• Interface requirements for
inter-application
communication
• Technical requirements
2. Identify
reference models,
tools, viewpoints
6. Review and
verification
3. Develop
5. Create logical
architecture
topology model for
descriptions
every app. incl.
relationships
4. Gap-Analysis
 Applications
 Application
communication
 Properties
 User
 Technical requirements
 Logical automation models
on a conceptual level
 Topological overview
• Description of applications at non-functional and
logical sight
• Reuse existing information and artifacts
 Target Information System
Architecture
• Verify stakeholders concerns at the GAP
Analysis
• Create TOSCA specific models at a logical level
Approach
SaaS / PaaS Layer
Objectives
• Creation of company specific topology
models for automation
• Prerequiste for automated deployment and
redeployment (idempotent)
• Plans for orchestration
Input
• Architecture Vision
• Baseline Technical
Architecture
• Technical requirements
• Technology
• Platform
• Information System
Architecture
(Baseline + Target)
• Logical automation models
on a conceptual level
Output
11. Complete
Architecture
1. Vision /
10. Feedback /
Requirements /
GAP Analysis
Uptake Baseline
2. Gather
Information
9. Handover for
verification and test
3. Identify
reference models,
8. Test by
tools
deployment Team
4. Risk analysis
7. Roll out
5. Dev. target
6. Validate
reference model architecture
• Target technical architecture
• Validation of Topology
Models against
Infrastructure and Business
Architecture
• Automated deployment
through orchestration
• Use TOSCA as describing metamodel
• Assessment of existing Architecture
• Adaption of company specifics
• Interviews with specialist department
Approach
• Dipl.-Ing. Albrecht Stäbler, Beratender Ingenieur; Consulting Engineer
• [email protected]
• Dipl.-Inform. Andreas Tönne, CTO dibuco (digital business company
www.dibuco.de)
• [email protected]