The Role of the Software Architect Jeff Lemich CMSC435.

55
The Role of the Software Architect Jeff Lemich CMSC435

Transcript of The Role of the Software Architect Jeff Lemich CMSC435.

Page 1: The Role of the Software Architect Jeff Lemich CMSC435.

The Role of the Software Architect

Jeff LemichCMSC435

Page 2: The Role of the Software Architect Jeff Lemich CMSC435.

Intro – Leadership Team – One Option

Managing DirectorSteering Committee

Project Champion Project Manager Project Architect

QADocumentation

Data Administration

SoftwareDevelopment

Managers

FunctionalManagers

SystemsOperations

Product ControlDBA

Page 3: The Role of the Software Architect Jeff Lemich CMSC435.

Not having the support of management.

Starting a project without a champion.

Thinking that the Project Manager role and the Architect role are the same.

Page 4: The Role of the Software Architect Jeff Lemich CMSC435.

Skills Any successful system must be built on a

single vision. You must be able to visualize abstract ideas.

Providing and communicating that vision is the primary function of the architect.

An architect must not only see the forest but the trees and the watershed that makes it possible.

Page 5: The Role of the Software Architect Jeff Lemich CMSC435.
Page 6: The Role of the Software Architect Jeff Lemich CMSC435.

Skills An architect starts with a blank sheet of paper. You must have expertise in data modeling,

software modeling, and related tools. http://www.databaseanswers.com/modelling_tools.htmhttp://www.objectsbydesign.com/tools/umltools_byCompany.html

If you are uncomfortable with the unknown, don’t be a software architect.

You must be creative. Analysis and developers will bring the problems they can’t solve to you.

Page 7: The Role of the Software Architect Jeff Lemich CMSC435.

Skills You must be able to multitask. There will be

many simultaneous projects in different stages of development taking place.

You must be able to answer most questions immediately without referencing documentation.

The project manager will depend on you for design and technical expertise.

You can’t do it all. You must be willing to delegate, be receptive to criticism and ideas, and to promote individual creativity.

Page 8: The Role of the Software Architect Jeff Lemich CMSC435.

Intro

All software has an architecture Unplanned Subsystem level System level Enterprise level

Page 9: The Role of the Software Architect Jeff Lemich CMSC435.

Unplanned Architecture – Shanty Town

Page 10: The Role of the Software Architect Jeff Lemich CMSC435.

Unplanned Architecture

Use free materials Constructed by non-professionals No engineering Has very few rules Can be built very fast No foundation

Page 11: The Role of the Software Architect Jeff Lemich CMSC435.

Subsystem Level Architecture

Page 12: The Role of the Software Architect Jeff Lemich CMSC435.

Subsystem Level Architecture

Uses standard materials Units constructed by building professionals Has some additional rules

Building codes Covenants Directly connected to utilities

Takes some planning Built on footings

Page 13: The Role of the Software Architect Jeff Lemich CMSC435.

System Level Architecture

Page 14: The Role of the Software Architect Jeff Lemich CMSC435.

System Level Architecture Designed by an engineer or architect Integrated utilities Integrated units

Common halls, Lobby, Elevator

Engineering standards Has many additional rules Requires a full foundation

Page 15: The Role of the Software Architect Jeff Lemich CMSC435.

Enterprise Architecture

Page 16: The Role of the Software Architect Jeff Lemich CMSC435.

Enterprise Architecture

Full needs of users / across systems Multiple turf issues Needs advanced architecture and

engineering Integrated utility systems Multiple functions (office / housing) Requires an extensive foundation

Page 17: The Role of the Software Architect Jeff Lemich CMSC435.

Terminology Application – One function (Display Grades) Sub-system – One process (Grading) System – Tightly integrated processes

(Student Records) ERP system – Multiple integrated systems

(Student Information System) Enterprise system – One organization

(Multiple integrated ERP systems)

Page 18: The Role of the Software Architect Jeff Lemich CMSC435.

CP-ONE - Enterprise system

2,000+ Applications/modules (4,500 programs/class) 175+ Menus 85 Sub-systems 1,707 Administrative Users + 35,000 Students + 3,674 Faculty + 55,000 Applications per year 827,000 Active People, 258,000 archived 7,516,627 Active Historic Course Records, 4,581,000 archived 18 Developers + 2 TAs (1 Director, 11 CP-ONE,

3 MF Packages, 5 Web)

Page 19: The Role of the Software Architect Jeff Lemich CMSC435.

Basics An organization may use a number of

architecture styles. Just because an organization is big doesn’t

mean it can’t be built as a shanty town. Unless you form your own company you

will not start as an architect.

Page 20: The Role of the Software Architect Jeff Lemich CMSC435.

Standards SA is mostly developing standards. When a developer is under a tight deadline

the last thing they will think about is standards.

Developers would rather do things the easy way. So make it easier to do things correct.

You must protect the architecture and standards after they are created!!

Page 21: The Role of the Software Architect Jeff Lemich CMSC435.

Standards Surprisingly increase creativity Build standards by consensus where

possible. It produces personal buy-in. As-good-as isn’t Better is better only is if it is worth changing

all other instances of the rule. Every rule is meant to be broken if needed.

It creates a new rule.

Page 22: The Role of the Software Architect Jeff Lemich CMSC435.

PERT/CPM

Will increase productivity and developer satisfaction more than any thing else.

When you start a task you have all the needed resources. Tools like MS Project help. (If used correctly!) Allow for multiple concurrent waterfall development processes.

Page 23: The Role of the Software Architect Jeff Lemich CMSC435.
Page 24: The Role of the Software Architect Jeff Lemich CMSC435.

Software Architecture Steps Rendering Site and resource planning Foundation Utilities Supports Floor Work Penthouse Maintenance Renewal

Page 25: The Role of the Software Architect Jeff Lemich CMSC435.

Rendering

Page 26: The Role of the Software Architect Jeff Lemich CMSC435.

Rendering What is it expected to do. How big will the system be. How is it expected to grow. Who are the users. How dynamic will it be. Is it commercial or private. What environment must it work in. What resources and funding are available?

Page 27: The Role of the Software Architect Jeff Lemich CMSC435.

Rendering

Major systems are now almost exclusively new renditions and integration of existing systems.

This is the step where the overall vision is established.

Don’t take this step lightly. Mistakes here can doom a project.

Page 28: The Role of the Software Architect Jeff Lemich CMSC435.

Site and Resource Planning

Page 29: The Role of the Software Architect Jeff Lemich CMSC435.

Site and Resource Planning How will this system relate to outside systems? What language, database/s and hardware/s will

the system use? Why? What development environments and tools will be

used? Who are the key players and management

structure? Where will the developers come from, be located,

and what experience do they have?

Page 30: The Role of the Software Architect Jeff Lemich CMSC435.

Site and Resource Planning What subsystems are the most important. How do the subsystems relate to each

other. What are the dependencies between

systems. Where is the data now? How much is

there? In what locations? How clean is it? What is the impact of data migration on the old system? Will it change dependencies?

Page 31: The Role of the Software Architect Jeff Lemich CMSC435.

Site and Resource Planning Where is the existing code? Do we have

the source code? Can we weed out the junk? Is it readable and well structured? Can we save any of it?

Do we have available the most important business rules? In code? On paper?

Do we have access to filled in paper forms? Lookout for writing in the margins!

Page 32: The Role of the Software Architect Jeff Lemich CMSC435.

Analysis Paralysis

Page 33: The Role of the Software Architect Jeff Lemich CMSC435.

Foundation

Page 34: The Role of the Software Architect Jeff Lemich CMSC435.

Foundation – For all systems CP-ONE Standard Authentication, State and Session Management Standard Application Look and Feel Standard Screen Headings Standard Function Key and Web Button Usage A Help System with Hyper-Link Capabilities Standard Code Lookup Capability Name search capabilities Standard Date and Term Edits and Processing A Command Line

Field on Applications to Facilitate Movement between Applications A Common Navigation and Menu System Application Access Security Application Function Security Value Security

Page 35: The Role of the Software Architect Jeff Lemich CMSC435.

Foundation A Work Flow System An Aliasing System Flow Control Capabilities to Eliminate Reentering of Key Data

When Switching Applications Standard Error Processing A Standard Way for Applications to Communicate with Each

Other Standard Audit Tables and Processes Standard On-line Batch Control Parameter Models A Standard E-mail Interface for Applications The Ability to Close Sub-systems for Maintenance General and Sub-system Welcome Messaging

Page 36: The Role of the Software Architect Jeff Lemich CMSC435.

Foundation Standardized Printer Definition and User Selection A Generic Text Editor Available to Applications A Generic Way to Add Free Format Notes to Applications Application Models A Mail-Merge Sub-system A Mailing Label Sub-system Batch Dynamic Allocation Capabilities Name Formatting Batch Sorting CP-ONE System Reports

Page 37: The Role of the Software Architect Jeff Lemich CMSC435.

Utilities

Page 38: The Role of the Software Architect Jeff Lemich CMSC435.

Utilities – For related systems Utility Addresses Utility College Master Utility Standard Code Table(s) Utility Degree Honors Utility Department Master Utility Degree Ranking

Page 39: The Role of the Software Architect Jeff Lemich CMSC435.

Utilities Utility Home Page Utility High Schools Utility School Master Utility Term Control Utility Term Dates Utility University Master

Page 40: The Role of the Software Architect Jeff Lemich CMSC435.

Thinking any of the steps up to here

can be skipped.

Page 41: The Role of the Software Architect Jeff Lemich CMSC435.

Supports

Page 42: The Role of the Software Architect Jeff Lemich CMSC435.

Supports Defining structures of the organization. The primary tables that most applications

will use and the objects that support them. How the data in those tables will be loaded

from legacy sources. Will all or parts of the legacy system and

the new system need to run parallel for a period?

Page 43: The Role of the Software Architect Jeff Lemich CMSC435.

Bad Primary Keys,Data Structures,

and Principal Object Relationships

Page 44: The Role of the Software Architect Jeff Lemich CMSC435.

Floor Work

Page 45: The Role of the Software Architect Jeff Lemich CMSC435.

Floor Work Subsystem design and development Smaller versions of the whole process but

with the infrastructure already in place. Use PERT to determine the best order for

subsystem development. Can an assembly line be partially used? By the time you get here you should have

very good metrics to estimate benchmarks.

Page 46: The Role of the Software Architect Jeff Lemich CMSC435.

Floor Work

Don’t forget everything else taught in this

Software Engineering course!!!

Page 47: The Role of the Software Architect Jeff Lemich CMSC435.

Watch out!This is where

specification creep can doom the project.

Page 48: The Role of the Software Architect Jeff Lemich CMSC435.

Penthouse

Page 49: The Role of the Software Architect Jeff Lemich CMSC435.

Penthouse The executive management subsystem Uses summary data from the other

subsystems Assesses the health of the organization Identifies trends Pinpoints potential problems

Page 50: The Role of the Software Architect Jeff Lemich CMSC435.

Maintenance

Page 51: The Role of the Software Architect Jeff Lemich CMSC435.

Maintenance Fix bugs Watch out for table growth Subsystem enhancements New system interfaces Even new subsystems How will new technology be utilized and

integrated? Should it?

Page 52: The Role of the Software Architect Jeff Lemich CMSC435.

Renewal

Page 53: The Role of the Software Architect Jeff Lemich CMSC435.

Renewal / Why? Rendition –Mission and scope change Site and resource planning –

Basic technology or hardware change Foundation – Basic design change Supports – Organizational change Maintenance – Excessive exception coding,

lost support staffing, technology no longer supported

Page 54: The Role of the Software Architect Jeff Lemich CMSC435.

Renewal / When?

Page 55: The Role of the Software Architect Jeff Lemich CMSC435.

SummaryNormalization Do It once

Sequencing Do it in order

Standards Be consistent

Support You can’t do it alone