Transcript Creating an IT Production Architecture function

Dennis Adams
associates
Management and Infrastructure SIG Meeting
Creating an
IT Production Architecture function
(the forgotten architecture)
Dennis Adams
21st February 2007
21 February 2007
Introduction - Some searching questions
•
•
•
•
•
•
•
•
•
Is IT an engineering discipline?
If so, how come we get so many things wrong so frequently?
Why does such as large percentage of projects go wrong?
Why are the costs of IT so huge?
How do we handle the huge legacy of applications we are
expected to look after, without being swamped?
Are there ways we can guarantee better quality of code
deployed into live?
I don’t have any answers
… but I do have some ideas…
One key is ARCHITECTURE
21 February 2007
Topics to cover
• Development and Production - two different cultures
• What is "Production-worthiness"? - Definition.
• How to assess applications for Production
Worthiness
• Building the relationships between Production and
Development
• Production Architecture in the Context of Enterprise
Architecture.
• Establishing Production Standards.
• Building Applications for the "Long Term"
21 February 2007
The Cost of Poor Application Performance
Top 2,000 European businesses spending more
than three million working hours every year trying
to get to the root of poor applications performance
(equates to €250m).
25 per cent of ICT directors and managers admit
they do not know all of the ways in which their
corporate networks are being used.
Coleman Parkes research January 2004
21 February 2007
Nightmares
Because of the slow speed of the database,
the project will develop an in-house cache
mechanism for static data, with integral
cache contention and refresh mechanisms.
“This project assumes
that the Wide-Area
Network Bandwidth is
infinite”
21 February 2007
• Response time should be
0.2 seconds in all cases.
• The number of users is
undefined.
The changing IT APPLICATION LANDSCAPE
• Mainframe
• Departmental
Computing
• Client/Server
Applications
• N-Tier Applications
• Message-Oriented
Middleware
• Composite Applications
linked together by a
Service-Oriented
Architecture: Enterprise
Service Bus.
21 February 2007
Changes in APPLICATION DEVELOPMENT
• Tools:
– Text Editors
– 4GL Intelligent Editors
– Integrated Development
Environments (IDEs)
– Sophisticated Debugging
– Integrated Test
Environments
– Design/Develop/Deploy
Environments (Eclipse)
• Techniques:
– Waterfall
– Prototyping
– Iterative Development
As Development has become more complex,
so too have Deployment and Production.
21 February 2007
DEPLOYMENT into IT PRODUCTION
IT
Development
21 February 2007
IT
Production
IT Department
Development
Teams
Create
New
Applications
Production
Teams
Support
Existing
Applications
21 February 2007
The two different sides of IT
• IT Development
–
–
–
–
–
Business Functionality
Speed of Delivery
Cost of Development
Development Projects may take months
Creating Competitive Advantage and ROI for the Business
• IT Production
–
–
–
–
–
Reliability, Resilience
Stability, Scalability
Cost of Support & Maintenance
Production Support may be required over many years.
Delivering Day-to-Day Competitive Advantage and ROI for the
Business
IT Development and IT Production think and act differently.
21 February 2007
Enterprise Architecture and Production Architecture
• Enterprise Architecture is charged with taking a
“helicopter view” of what is being developed and
managed in the enterprise.
•
•
•
•
Goals:
Deliver successful applications.
Deliver business benefit.
Applications that Work.
An Enterprise Architecture Approach,
properly implemented,
should be able to address the needs of both
Development and Production
21 February 2007
Production Architecture - Organisational Context
Business
IT Development
Business Sales
and Operations
Business Sponsor
Business Users
Client / Service
Managers
Business Analysts
Application
Developers
Application
Architects
Project Manager
21 February 2007
IT Production
Project Manager
Security /
Availability /
Capacity
Planning
Technical
Teams
Infrastructure
Architects
Project Manager
Some Architectural Frameworks
• TOGAF ( http://www.togaf.org )
– Enterprise Architecture framework (“bits and bytes”)
– Architecture Vision => Business Architecture => Data =>
Application => Technology => Solution
– Emphasises the importance of Architecture Board & Governance.
– Has a formal certification exam.
• ZACHMAN ( http://www.zifa.com )
– Systems Architecture Viewpoint
– 6 basic questions (What, How, Where, Who, When, Why)
– 5 stakeholders (Planner, Owner, Designer, Builder, Subcontractor)
• RUP & ERUP ( http://www.ibm.com )
– Iterative Software Development processes owned by IBM
– Inception => Elaboration => Construction => Transition
– Developed into the AGILE Unified Process
21 February 2007
IT Production “touch points” in Development
TASKS
P1
P2
P3
DEFINE FUNCTIONAL AND
P4 NON-FUNCTIONAL
P5
P6
P7
REQUIREMENTS
Project
Launch
Requirements
Gathering
Design
Options
Build
Integrate
Deploy
21 February 2007
GO LIVE
What makes a project successful in PRODUCTION?
Question for the Audience
21 February 2007
Why PRODUCTION STANDARDS are IMPORTANT
• In some cases, the choice of Technology for a new Application
can be driven by Developers’ Choice:
–
–
–
–
Useful Development Tools ?
Design and Development Features ?
Familiarity ?
The desire to try out the latest technology ?
• Result: Applications whose Development costs may be Low, but
the Support Costs may be high (even prohibitive).
• Defining IT Production Standards can redress this balance.
• Standards can contribute to controlling Costs of Maintenance &
Support
• Simplicity = Economies of Scale in Support
21 February 2007
Production-Readiness Criteria
Terminology Definition
Can it can scale to the number of users / application instances etc. w hich may be required? As the number of end-users or application
instances increases, howm uch (proportionally) additional hardw are e tc. is re quire d in orde r to de live r the e xtra capacity?
To w hat extent can the application be enhanced and expanded to adapt to possible f uture requirements?
Can this solution be expanded to address f uture requirements? Clearly, this is not a simple prediction to make, but the purpose of this
Expanability
question is to guard against chosing solutions that paint the organisation into "technological corners"
Stability is the ability to be able to run unattended forlong pe riods of tim w
e ithout operational intervention. Reliability theref ore has to
Re liability
do w ith predictable, repeatable behaviour, w hereas Stability has to do w ith repeatable behaviour over time.
Stability is the ability to be able to run unattended forlong pe riods of tim w
e ithout operational intervention. Reliability theref ore has to
Stability
do w ith predictable, repeatable behaviour, w hereas Stability has to do w ith repeatable behaviour over time.
Re s ilie nceis the ability to re cove r quick ly from a failure of one or m ore com pone
that
ntsmake up an overall system.
Resilience assessment is concerned w ith how to implement Clustering mechanisms to guard against the possibility of failure of an
Re s ilie nce
Operating System, and how to ensure that there is no single point of failure w ithin the architecture.
Resilience also includes an assessment of how to implement Disaster Recovery mechanisms, and how to implement of f -site recovery.
Back up extends the idea of Resilience to look at how to respond to the
failure of all com pone ntsThis
. is typically implemented by using
backup & recovery techniques. For example, f ailure of an entire data centre.
Back up
Secondly, Backup can be used in order toer cove r the s ys te m to a k now n s tate at a s pe cific pe riod of. One
tim ereason might be that
some business logic (or dependant application) has resulted in corruption and it is necessary to go back in time to recover. A second
reason may be to build an archive or historical copy of the application f or the purposes of analysing historical trends, or setting up a test
Re cove ryis key corollary to backup. Assuming that it has been show n that the system can be backed up, this section addresses the
Re cove ry
questions of how long recovery w ould take, and how much loss of data may be result.
Se curityconcerned not only w ith thes e curity of the application
as presented to the end user (e.g. the ability to implement IP f ire w alls,
Se curity
packet f ilters etc.), but also w ithis olationof the Production Application f rom any development / test versions. For example, w hat is to
prevent a developer f rom calling the Live Production business logic f rom w ithin an application sub-net.
One of the purposes ofm onitoringis to pro-active ly ide ntify any adve rs e change s in the be haviour of the s ys
and/or
te m it's
environment, in order to take appropriate corrective action bef ore the change impacts the business client. For this reason, "Monitoring by
M onitoring
exception" is most appropriate.
A second f orm of monitoring is"tre nd analys is,"the purpose of w hich is to extract time-series data in order to model the long-term
M anage m e ntis also another key role in IT Production. In this case, w ere are concerned w ith
how e as y it is to am e nd or adjus t the
M anage m e nt configuration of the application
, and adjust it's environmental behaviour. Such conf iguration should be as automated (and intuitive) as
possible, in order to minimise IT Production costs f or supporting the running application.
Supportabilityis def ined as the features w hich make the application or system able to be supported by a "Business as Usual" IT team.
This is a general extension of the concepts of Monitoring and Mangement, above.
Supportability
The signif icant issue w ith the "Supportability" assessment is
w he the r the application can be s upporte d at a re as onable cos
In t.
21 February
2007
practice,
this means ensuring that w e can minimise the amount of manual intervention required to keep to application at its appropriate
Scalability
PRODUCTION-READY: Defined
• Scalability
– As the workload increases, how much additional hardware etc. is
required?
• Expandability
– Can be adapted to possible future requirements?
• Reliability
– Deliver results consistently & repeat ably, irrespective of changed
circumstances ?
• Stability
– Able run unattended for long periods of time without intervention?
• Resilience
– Able to recover quickly from a failure of one or more components of
the overall system?
21 February 2007
PRODUCTION-READY: Defined (2)
• Backup
– Able to respond to the failure of all components of the system?
• Recovery
– Able to restore the system to a known state at a specific period of
time?
• Security
– Are Users authenticated and Authorized, and non-users Isolated?
• Monitoring
– Able to pro-actively identify any changes in the behavior of the
system?
– Able to extract time-series data to model the long-term behavior?"
• Management
– How easy is it to amend or adjust the configuration of the
application, and it's environmental behavior?
• Supportability
– able to be supported at a reasonable cost?
21 February 2007
Production-Readiness Suitability Assessment
Clie nt
Pre s e ntation
Ne tw ork 1
Bus ine s s
Logic
Scalability
and
Expandability
5
4
5
5
4
4
5
32
Re liability
and Stability
4
4
5
4
4
4
5
30
Re s ilie nce
5
5
4
5
3
3
5
30
Back up and
Re cove ry
5
5
5
4
3
4
5
31
Se curity
3
3
5
3
4
4
5
27
M onitoring
and
M anage m e nt
5
2
3
5
4
5
5
29
Supportability
5
4
5
4
4
5
5
32
32
27
32
30
26
29
35
21 February 2007
Trans actional Ne tw ork 2
Pe rs is te nce
Value
M e aning
Support Cos ts
1
Application or System is considered to be totally
unsuitable f or IT Production use.
Costs of support are likely to be
prohibitively high if the application or
system w ere ever introduced into IT
Production.
2
This Version of the Application or System is considered
to be unsuitable f or IT Production use, but could be
Costs of support are likely to be very high
used f or sof tw are development, and additional
if the application w ere ever introduced into
discussions w ith the vendor should be held in order to IT Production.
introduce required f eatures in a f uture version.
3
4
5
Application or System is recommended f or deployment
into production w ith some additional customisation
required by the client or vendor in order to improve
supportability.
Application or System is suitable f or Production
deployment, w ith very little additional customisation
required. The client can implement any such
customisation, w ithout any necessity f or involvement
f rom the vendor.
Application or System is suitable f or Production
deployment, w ith minimal customisation. The vendor
has demonstrated a strong understanding of the
principles of ÒProduction WorthinessÓ, w hich are
ref lected in the design and implementation of the
product.
21 February 2007
Costs of support are likely to be in line w ith
costs f or other applications of this type.
Costs of support are likely to be in line w ith
costs f or other applications of this type.
Costs of support are likely to be in line
w ith, or less than, costs f or other
applications of this type.
IS a Solution PRODUCTION-READY?
“Simplicity remains one of SOAP's primary
design goals as evidenced by SOAP's lack of
various distributed system features such as
security, routing, and reliability to name a
few.”
Understanding SOAP
Aaron Skonnard
MSDN, March 2003
http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/dnsoap/html/understandsoap.asp
21 February 2007
INTERFACING PROCESSES
Initiation
R&D
Configuration
Release
Build
Standards
Change
Problem
Deploy
Support
21 February 2007
Handover
Incident
Service Desk
Establishing Standards for future Projects
• Establish a Production Architecture role
– Define Production Readiness Criteria
– Engage with Development
– Publish Technology “menu” of Production Standards
• Developers and Business need to understand that
these Standards represent the optimum support
costs for Applications.
• Engage with Developers at Project Initiation.
• Configuration Baselines affect charge-back
• Template SLAs should reflect these Standards
• Establish processes for amending these Standards
Choice of Standards should depend upon whether or not a
Technology is “Production-Ready”
21 February 2007
Taking the Long Term View
COST
Develop
Test /
Deploy
Design
Production
21 February 2007
TIME
Standards
Choice of “best of breed” technologies
Clear Architecture
Validation
Governance
21 February 2007
Procedures
Dennis Adams
associates
Questions ?
21 February 2007
WORKSHOP: Assessing A Product Chose
• Background:
• You are working as an Oracle DBA in the IT Production division
of a medium-size organization.
• The company is considering how best to implement High
Availability (HA) for Oracle databases.
• Cost is not an issue (!)
• Two options have been considered:
• Oracle RAC
• Oracle Dataguard
Conduct a Production Suitability Assessment
to determine which is the better choice from an
IT Production perspective.
21 February 2007
Dennis Adams
associates
Management and Infrastructure SIG Meeting
Creating an
IT Production Architecture function
(the forgotten architecture)
http://www.dennisadams.net/event200702oracle.htm
Dennis Adams
21st February 2007
21 February 2007