Downloaded 49 times
Uploaded byAnoushiravan M. Ghamsari
The Role of a Systems Architect
The document outlines the role of a systems architect, highlighting the importance of a holistic, requirements-driven approach to systems architecture that encompasses both technical and business considerations. It details various structured methods, skills required, and different scenarios where a systems architect would provide solutions to IT-related problems. Additionally, it emphasizes the relationship between enterprise architecture and systems architecture, comparing it to urban planning to illustrate the need for adaptable and robust frameworks.
More Related Content
Similar to The Role of a Systems Architect
The Role of a Systems Architect
- 1. The Role ofa Systems Architect Paul Booth, Senior Consultant IT Architecture & Strategy paul_booth@uk.ibm.com 01256 344774
- 2. What is aSystems Architect?
- 3. The holistic approach End-to-end(holistic) Requirements-driven Requirements Analysis End-to-End Systems Architecture Viability - Non-functional Requirements Performance (response times, etc.) Availability (# breaks per year, etc.) Operability / Systems Management Security Etc. Structured Method Global Services Method Enterprise Architecture Method End-to-End Design Method SMFD (Systems Management) Availability Method Performance Engineering method
- 4. The T-shaped skillsprofile Breadth of understanding & skill across IT Depth of technical expertise
- 5. Enterprise Architecture (EA)relative to End-to-End Systems Architecture (E2E) Enterprise Strategy Data IT Strategy Architecture Process Architecture Enterprise Architecture EA Current Systems 2E E ABC system 2E E DEF system 2E E GHI system 2E E etc..
- 6. An Enterprise Architecture(EA) is much like a city plan in that it defines an infrastructure that will meet the current and future needs of a diverse user population and will adapt to changing business requirements and technology. Architecture Components Usage City Planning Analogy Vision Strategy for I/T use across the enterprise City vision based on anticipated needs of residents Principles Guidance for investment and design decisions Zoning and building codes to ensure quality & consistency in construction Models Overall context and views for systems and users Maps and diagrams for infrastructure systems like water, sewer & electric Arch. Building Blocks Standard Components for high level design Prefabricated building component specifications for off-site construction Criteria Considerations for standards and product selection Considerations for component selection such as durability, cost, etc. Standards Guidelines to which systems must conform Electrical wiring and plumbing standards Arch. Mgmt. Process Process to allow additions & variances to Architecture Process to change the city plan and allow for variances Transition Initiatives & Plan Prioritized infrastructure projects & costs City improvement plan
- 7. Dealing with Fuzzyproblems The Systems Architect Management: "I know I have a problem - it's impacting my business. But technically I don't really know where to begin." Qualify the situation Analyse background & context Define problem Recommend and plan project to handle problem Resource team with appropriate skills Carry out research Make recommendations Problem Statement or Analysis Solution Recommendations
- 8. Systems Architecture situations(1) The client has.. IT-related problem Business requirements (possibly incomplete) The client needs.. A solution Outline of system solution & its feasibility Existing infrastructure Technical direction needs evolution System Architect.. System Architect produces.. Defines problem Problem Analysis Report Recommends actions Problem Recommendations Analyses & completes requirements Requirements Analysis Creates first-cut IT System Feasibility Report solution System Proposal Reviews technical feasibility Establishes business & technical context Technical Strategy Report Creates a recommended strategy
- 9. Systems Architecture situations(2) The client has.. The client needs.. System Architect.. System Architect produces.. Fundamental change or increase in scale New technical Uses structured approach toEnterprise Technical Architecture to existing architecture or system create an architecture or Report, infrastructure model design Technical Infrastructure Design coming up Project with many disparate elements, Uses structured method to Technical Audit Report, or application but not Overall system design review design elements and System Architecture Report, technical create cohesive design Technical Infrastructure Design infrastructure Reviews technical design in Technical Audit / Assurance Project under way or Assurance of technical structured way. Report, in plan viability Creates systems System or Technical Architecture architecture if necessary.
- 10. Systems Architecture situations(3) The client has.. Under-performing system (availability or response) Project starting The client needs.. System Architect.. System Architect produces.. Establishes where in end-toPerformance Analysis, Recommended way end system the problem Availability Analysis, forward lies. Scalability Analysis Recommends actions. To know what tasks Works with PM to create Work Breakdown Structure, required, in what order work breakdown structure Plan
- 11. Benefits to theclient IT Raises technical integrity of solution (i.e. it works better & offers better service to business) Increases flexibility, scalability, adaptability (etc., etc.) of system Positions IT better for business change Business Spur to creativity, innovation Reduces & manages risk Lowers cost and raises quality overall Ties IT actions more closely to business
- 12. What skills doyou need to do this?
- 13. Understand the businessrequirements What does the business need? What business processes will be supported? What system components are needed to do this? Where are the business rules? Who are the key users? Who is really behind this?
- 14. Understand the technology PDA Laptopcomputer Disk (local, shared, NAS, SAN...) Windows, Unix, Linux, Solaris, z/OS, OS/400, ... DB2, Oracle, SQL Server... Java, ActiveX LANs, WANs, Routers, Firewalls RSA, SSL, Intrusion Detection Workstation Ethernet Laser printer Firewall Server Ethernet -business Workstation Mainframe
- 15. The data Underlying datastructures Tailored data groups Business Manager Tables Referential Integrity Interfacing requirements MIS requirements Imaging CLTROLE COMPANY NAME FONREF ADDRREF ADDRESS CLTDET CLTLOG CLIENT CLTTH CLIENTAS BILACT POLICY CLTACT CLTREF CLAIM PAYMNT
- 16. Architectural Alternatives Java enabled Webbrowser or Network Computer TCP/IP for OS/390 CICS TS for OS/390 V1R2 Web server (Lotus Domino Go Webserver) HUON EXC I IP P/ TC TP HT Firewall Client/Server or Webmodel Operational or Informational Flexibility vs. Performance Java for OS/390 CICS Java Gateway OS/390 Huon Server CICS Client HUON 'E' Program
- 17. Performance MVS tuning CICS tuning DB2tuning Efficient SQL Diagnostic tools: STROBE DB2PM EPDM OMEGAMON
- 18. The operational environment Theovernight schedule The data centre view of life Interfacing requirements Disaster recovery
- 19. Human factors Business scripts Dialogstructure Number of screens Layout of screens Drag and Drop CUA look and feel Sequence of fields Use of help Menemonics
- 20. The development process OverallDevelopment approach Tools Library management Debuggers Table data vs. code Standards and Guidelines Work activities
- 21. Management systems Risk management Projectdeliverables Escalation procedures Roles and Responsibilities Right of Veto Sign-off criteria
- 22. Testing What to test Typesof test Entry criteria Exit criteria When to stop testing DEVELOPMENT UNIT TEST INTEGRATION TEST SYSTEM TEST SINGLE THREAD VOLUME STRESS ACCEPTANCE
- 23. The Compleat architect Abrain the size of a planet Eyes in the back of the head The memory of an elephant The armament of a tank The creativity of Salvador Dali An understanding spouse
- 24.
Editor's Notes
- #3 To some people, a Systems Architect is someone who designs the internal structure of a business application. To others, this person designs the operational platforms (HW, SW, middleware, networks) that support applications. Make sure you are all on the same wavelength when using the phrase “Systems Architect”.
- #4 In the eighties, the world moved from centralised DB/DC transaction processing systems into distributed processing architectures. We saw an increase in the complexity of the solutions. People tended to specialise in particular pieces of the solution puzzle; nobody took the holistic, overall view of the end-to-end technology chain. The result was that system would be commissioned which failed to meet the required targets of Availability, Performance and Serviceability. This led to the emergence of Methods to ensure that architects considered non-functional requirements from the earliest stages of the design.
- #5 But where to get such an architect with such an end-to-end grasp of the design ? We found the best way was to grow them through specialisation in one or two technical areas to build their self confidence. Then, with a foundation in this skill, they could start to branch out to other areas – not in depth – but drawing on their experience in their own subject.
- #6 Classically, an Enterprise should set its strategy, then the IT Director should set IT Strategy to support that. You sometimes find a Data Architecture, and frequently a Process Architecture support the main IT areas of interest. Then underpinning (delivering) all of this comes the Enterprise’s Technical Architecture – the EA. This addresses the broad sweep of IT standards and standardised building blocks across all the business systems (applications). IBM has the Enterprise Architecture Method to address this layer. It also had the End-to-End System Design Method (E2E) to address the individual business systems. (E2E is now part of a later method called GS Method).
- #7 It is sometimes useful to draw this parallel between an Enterprise Architecture and a City Plan.
- #8 The Systems Architect can be called upon in a variety of situations. Helping management to grapple with a fuzzy problem is quite common.
- #9 The next three slides show in more detail the typical situations in which a Systems Architect helps management solve a problem.
- #13 The Systems Architect needs to have a wide range of skills in order to support sensible design decisions and recommendations. The main skills are covered in the next set of slides. Since it is unlikely a person will possess all these at the beginning of their career, the single most important one is the ability to recognise when and how to call in specialist support.
- #14 The Systems Architect tends to work closely with the Business Architect. The boundary between their disciplines, and the common language they need to share, tends to be the output from Business Process Modelling.
- #15 They need to be fluent in matters of technology.
- #16 Typically the Systems Architect only needs to understand the gross characteristics of large accumulations of data, rather than the fine detail of the physical data model.
- #17 It is common to be confronted with alternative design choices, frequently with strong and conflicting reasons for both. The Systems Architect learns techniques to cope with this challenge and guide all parties towards an agreed solution.
- #18 The Systems Architect needs to be able to make broad performance assessments, to ensure that it falls well within acceptable limits. If these estimates suggest that achieving required performance will be a close-run thing, it is time to adjust the design or, if this is unacceptable, to call in a performance specialist.
- #19 The Architect needs to understand what is involved in running real systems; how Service Delivery departments work, what are the challenges of meeting overnight deadlines month after month; what to do to recover from disasters and so on.
- #20 Human factors tend to be more the province of the Application Architect.
- #21 The Systems Architect should seek to support the process of deciding the Development approach and particularly the Development Environment. If not, then you could find that several characteristics will have been set in concrete through the choices made for development tools. Without the long view of the Systems Architect, there can be risk that these choices are made principally to meet development deadlines, not the long term viability of the live environment.
- #24 In summary the System Architect needs to have many assets.