IT Architecture and Architects

Dovgal Solutions
Inc.
Presented by Andre Dovgal
IT Architecture and
Architects
2022
© Dovgal Solutions, 2022

let’s start with the question
2
What is the main reason for Information
Technology architecture?
To deal with complexity of information
systems
2022 © Dovgal Solutions Inc.

and yes, they have become really complex…
3
Past: MS-DOS v.1 (1981) total size was 8KB
Present: Modern OS - Gigabytes
Past: Coding started with small monolithic programs
Present: Today there are distributed environments of heterogeneous
software. This image is not a poorly-drawn world map. It is a
map of all Internet data centres (8.5 million in 2017)
• Complexity is not just the structure of code, but it is also related to sustainment processes. Software becomes
more difficult to maintain and support, as a direct result of increased complexity.
• Cost of software bugs, glitches, and security failures worldwide was more (and probably, much more) than
$1.1Trillion in 2016. Tricentis
• One may argue that the complexity of information systems adds to the commonly seen disconnect between
business and IT.

Application Services
Enterprise Service Bus
Services
Messaging Services
Service 1 Service 2 Service 3 Service 4 Service 5 Service (n)
User
Employee
Member
External
Partners
Provider
Consumer
Development Services
Partner
Operations Services
Governance
Versioning
Controlled
Deployment
Configuration
Management
Service Lifecycle
Mgmt
Service Registry
Industry Common
Messaging Patterns
Msg Attachment
Delivery
Transaction
Processing
Workflow Reliable Delivery
Idempotence
Mapping and
Transformation
Routing
Sequencing
Queuing
Quality
Management
Change,
Configuration and
Release
Management
Frameworks
Solution
Delivery
Framework
Operational
Framework
Modelling
Service
Oriented
Modeling
Form /
Document
Design
Business
Process
Modeling
Development
& Authoring
Productivity
Tools
Integrated
Development
Environment
Business
Rules
Authoring
Channel
Services
Internal
Channels
External
Channels
Partner
Channels
User
Interaction
Services
Collaboration
Services
Presentation
Services
Business
Function
Services
Custom
Packaged
BPM Services
Business
Activity
Monitoring
Process
Repository
Process
Modeling &
Simulation
Process
Engine
Workflow
Automated/
Human
Task Mgmt
Info Mgmt Services
Op/Adhoc
Reporting
Form/
Document
Generation
Business
Intelligence
Data Mining
Data Quality
E-signature
Common Services
User Help
Training
Logging/
Audit
Alerting /
Notifications
Personalization
Correspondence
Search
Exception
Handling
Enterprise Content Management (ECM)
Capture Deliver
Store Preserve
Business Rules
Management System
Business
Rules Engine
Business
Rules
Repository
Rule /
Decision
Simulation
Manage
Content
Management
Collaboration
Web Content
Management
(Web Portals)
Records
Management
Workflow
and BPM
Migration/
Conversion
Information Architecture Layer
Information Management
Acquisition / Origination
Storage / Retention
Distribution
Manipulation / Processing
Information Representation
Information Exchange
Protocols
Information Structures
Migration / Conversion
Business Intelligence
Metadata
Enterprise Content Mgmt
Definition / Quality
Technology Services
Enterprise Security Services
Identity
Management
Audit &
Monitoring
Assessment
& Assurance
User
Provisioning
Integrity:
Transport
Integrity:
Storage
Trust Services
Integrity:
Platform
Access
Management
Service Management
Infrastructure Services (IAAS)
Platform as a Service (PAAS)
Database
Environments
Systems
Management
Software Dist.
and Patch
Management
Orchestration
/ Scheduling
Availability
Workload &
Capacity
Management
Environment
Management
Desktop
Services
(DAAS)
Billing
Change
Management
Supplier
Management
Service Level
Management
Service
Catalog
Management
Asset Mgmt
Release &
Deployment
Management
Configuration
Management
Service Desk
Problem
Incident
Event
ESB
Software as a Service (SAAS)
Messaging Email
Office
Productivity
Application
Platform
Sandbox DEV
QA
Pre-Prod Prod Train
DR
Remote
Apps
Remote
Desktop
Caching
Directory
Services
Network
Connectivity
Server
Compute Telecom
Server
Virtualization
Web Services
Data Cache
Print
Data Backup
Storage Data Restore
Replication
Client Devices
Data Center
Data Center
Managment
Data Center
Facilities
Block
File
Archival
Business Activity
Monitoring
Maintenance
Op Reports Quality of Service
ESB Monitoring
Architecture Building Blocks
4
example of complexity –
architecture building blocks
Acquisition/Origination of data
- analysis of existing process and systems
- analysis of different types of data: customer information, financial transactions, auxiliary data
- how the information is supposed to be collected: online, migration, internal process for data entry
- security – personal sensitive data, credit card information
- what are the industry standards? PCI? SOX – in US? What does the legal department of the organisation say? Any
province/state standards and/or recommendations?
- choosing the system – buy vs. build decision. How to support? maintain it? integrate? supported protocols? message
formats?
- choosing the system – comparison between different ones
- POC
- at what point do we validate data? At origination or at the end?
- consistency for different sources of origination?
- auxiliary systems – for example, postal code validation.
At the end we need to decide
- what we buy and what we develop
- how this component is integrated with others (including process, people, data, code, etc.)
- what requirements are not/ cannot be supported?
- roadmap
- what business process have to be changed or developed
- how the new system is maintained and supported
- system administration, configuration, monitoring
- design and development recommendations: platform, patterns, languages

benefits of IT architecture
5
• improved quality of information systems
• wholistic view of information systems as business systems
• achieved better business-IT alignment
• improved maintainability results in better sustainment
• clear goals of reliability, scalability, performance, security, interoperability
• minimized risks
• optimized costs

architecture and architects – so many…
Integration architect
6

only three IT architecture roles are more or less well defined in the industry
ARCHITECTURE CONTEXT
Software Architecture Software product development
Solution Architecture Project delivery
Enterprise Architecture Strategic planning
7
Some organizations and associations providing structure in architecture
domain and defining terminology (by no means a complete list):
• Iasa – An Association of All IT Architects
• WICSA – Working IEEE/IFIP Conference on Software Architecture
• SEI – Software Engineering Institute
• The Open Group
• Zachman International
• Business Architecture Guild

software architecture
8
• The concept and even the term ‘software architecture’
was first used in late 1960s.
• It became prevalent in early 1990s; many significant
concepts emerged (patterns and best practices,
complexity analysis).
• There is a number of opinions on what software
architecture is, and there is a number of definitions.
However, most agree that:
The architecture of a software system is a metaphor,
analogous to the architecture of a building
Software architecture:
- High level structure of a software system
- Discipline of creating such a high level structure
- Documentation of this structure

development vs. design vs. architecture
In the early days of software
development all developers
were both designers and
architects
9

code: design:
• code structure – class diagrams
• select algorithms
• select data structures
• use design principles (e.g., OOD)
• select design patterns
• component diagrams
• senior developers performing very complex design are often
called software architects
• the boundary between them is very blurry
• they may develop algorithms and design patterns
10
development vs. design

Payment
Gateway
BILLING SYSTEM
Industry
Messaging
Standards
PCI
Compliance
Data Security
IT
Department –
Operational
Reqs
Legal
Constraints
Resource
Constraints
Organization
Roadmap
NFRs
…...
Architecture
software design vs. software architecture
“All architecture is design, but not all design is architecture” – Grady Booch, 2006
• Design deals with internal dependencies of the software system itself;
• Architecture mostly deals with external dependencies.
Design
• Design decisions are mostly technical in nature;
• Architectural decisions have both technical and business reasons.
11

technical architects
12
• Software Architects focusing on specific technologies are often called Technical Architects
• If the technology is emphasized, the name is more specific:
• SharePoint Architect
• SAP Architect
• Salesforce Architect
• Dynamic 365 Architect
• …
• I believe that “technical architect” is not a good term, since architecture is not about
technology only, it’s also about business.

product development and project delivery require different architects
13
Architects
product development - software architects
project delivery - solution architects

solution architecture – always considered in the context of a project
and even sometimes called “project architecture”
• A project is a temporary endeavor designed to produce a unique product, service or
result with a defined beginning and end.
• Solution architecture establishes a path between the current state and the future
state of the system.
• Solution architecture establishes a bridge between business and technology.
• Standards
• Regulations
• Frameworks
• Roadmaps
14
• Business and technology constraints
• Business and technology dependencies
• Communication with business and IT
• Cost analysis
Solution architects deal with:
• Non-functional requirements
• Proofs of concepts
• Patterns and best practices
• Option selection

solution architecture vs. business analysis
15
• Both Business Analysts and Solution Architects deal with current
state and future state:
• Business Analysts focus on “what?” - requirements
• Solution Architects focus on “how?” - transition/solution
• Solution Architects provide guidance to Business Analysts in entire
requirement gathering process, particularly with
• Analyzing current state
• Analyzing integration with other systems
• Validating functional requirements
• Supporting NFR (non-functional requirements) gathering

solution architecture vs. project management
16
• Both Project Managers and Solution Architects provide a bridge
between business and technology groups.
• Both Project Managers and Solution Architects should be involved from
the very beginning (concept, pre-sales) to the very end (deployment and
stabilization) of the project.
• Solution Architects oversee the project from requirement gathering to the solution
release into production
• Solution Architects develop solution architecture and oversee its implementation
• Both are responsible for quality.
• However, not only Project Managers and Solution Architects perform
different tasks and are responsible for different deliverables, they also
own different risks:
• Project Managers – scope, budget, time
• Solution Architects – solution (business as well as technical aspects)

solution architecture and enterprise architecture
17
Solution architecture is guided and governed by enterprise architecture.

enterprise architecture
Enterprise architecture is NOT software architecture for enterprises
Enterprise architecture is NOT software architecture with enterprise quality
Enterprise architecture is NOT software architecture …
Gartner Group: “Enterprise architecture (EA) is the process of translating business vision and
strategy into effective enterprise change by creating, communicating, and improving the key
principles and models that describe the enterprise’s future state and enable its evolution.”
Enterprise Architecture deals with:
- Business and IT alignment
- Strategic IT planning
- Governance of solution architecture
Some EA frameworks and methods (there are many more):
- Zachman, DoDAF, frameworks developed by governments or large corporations
- In North America, TOGAF (or TOGAF-based frameworks) is probably the most popular
18

enterprise architecture and solution architecture
19
time
Infrastructure/ Technology
Data
Application
Business
Information
Systems
Architecture
Domains
Crosscutting
concerns
Enterprise Architecture
project starts project ends
Solution Architecture
SA SA

a few typical architecture deliverables
20
Conceptual
Architecture
Target Conceptual Architecture
Assumptions, Constraints, and Dependencies
Option Analysis
Solution
Architecture
Solution
Architecture
Transition Path
Target Architecture (business, data,
application, technology)
Architectural Approach
Baseline Architecture (business, data,
application, technology)
Business Drivers and Desired Outcomes
Baseline Architecture
Risks and Impacts
Reference to Requirements
Assumptions, Constraints, and Dependencies
Risks and Impacts
Governance
Option Analysis
Proof-of-Concept
Architectural Recommendation
Prescriptive Guidance
Architecture Definition
Capability Assessment
Architecture Strategy and Roadmap
Architecture Principles
Enterprise
Architecture
Maturity Assessment
Architecture Vision
Compliance Assessment
Cloud Strategy
Integration Strategy
Architecture Building Blocks
Solution Building Blocks
Migration Plan
Data Strategy
Reference Architectures
Application Landscape
Business Capabilities Map
...

architecture competencies
21
0
1
2
3
4
5
6
7
8
9
10
Leadership
Communication
Strategy
Organizational
Dynamics
Tactic/Process
Technology
Breadth
Technology
Depth
Solution Architect
Enterprise Architect

other architectures and architects
• Well defined terms – enterprise architecture, solution architecture,
software architecture.
• Well defined terms within standards – e.g. TOGAF: application architecture,
information architecture, technology architecture, business architecture.
• Industry-recognized proprietary frameworks (large organizations)– e.g. Microsoft:
solution architect, infrastructure architect; Fujitsu Macroscope: system architect.
Roles and titles in various organizations:
• SharePoint architect
• SAP architect
• integration architect
• security architect
• Web architect
• database architects
• technical architect
• abused terms: software architect, enterprise architect
22

agile architecture – is it an oxymoron?
23
Philippe Kruchten does not think so:
http://philippe.kruchten.com/2013/12/11/agile-architecture/
“The concept [of Agile Architecture] is not new: evolvability, software evolution,
re-engineering of existing systems have been studied and understood for a long time.”
“There is a naïve thinking that just by being agile, an architecture will gradually
emerge, out of bi-weekly refactorings.”
“The most common thinking nowadays is that architectural design and the gradual
building of the system (i.e., its user visible functionality) must go hand-in-hand, in subsequent
iterations, and the delicate issue is actually: how do we pace ourselves, how we address
architectural issues, and make decisions over time in a way that will lead to a flexible
architecture, and enable developers to proceed. In which order do we pick the quality attribute
aspects and address them.”

Questions?
Dovgal Solutions
Inc.
• Contact Andre Dovgal
• Email: andre@dovgal.solutions
• Phone: 604-345-0812
• Web: dovgal.solutions

IT Architecture and Architects

Recommended

Recommended

More Related Content

Similar to IT Architecture and Architects

Similar to IT Architecture and Architects (20)

Recently uploaded

Recently uploaded (20)

IT Architecture and Architects

Editor's Notes