The role of the software architect
This presentation is the property of its rightful owner.
Sponsored Links
1 / 55

The Role of the Software Architect PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

The Role of the Software Architect. Jeff Lemich CMSC435. Intro – Leadership Team – One Option. Recipe for Disaster. 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. Skills.

Download Presentation

The Role of the Software Architect

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

The role of the software architect

The Role of the Software Architect

Jeff LemichCMSC435

Intro leadership team one option

Intro – Leadership Team – One Option

The role of the software architect

Recipe for Disaster

  • 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.



  • 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.



  • An architect starts with a blank sheet of paper.

  • You must have expertise in data modeling, software modeling, and related tools.

  • 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.



  • 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.



All software has an architecture

  • Unplanned

  • Subsystem level

  • System level

  • Enterprise level

Unplanned architecture shanty town

Unplanned Architecture – Shanty Town

Unplanned architecture

Unplanned Architecture

  • Use free materials

  • Constructed by non-professionals

  • No engineering

  • Has very few rules

  • Can be built very fast

  • No foundation

Subsystem level architecture

Subsystem Level Architecture

Subsystem level architecture1

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

System level architecture

System Level Architecture

System level architecture1

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

Enterprise architecture

Enterprise Architecture

Enterprise architecture1

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



  • 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)

Cp one enterprise system

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)



  • 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.



  • 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!!



  • 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.

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.

The role of the software architect

Software like buildings

can't be built from the

penthouse down!!!

Software architecture steps

Software Architecture Steps

  • Rendering

  • Site and resource planning

  • Foundation

  • Utilities

  • Supports

  • Floor Work

  • Penthouse

  • Maintenance

  • Renewal





  • 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?



  • 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.

Site and resource planning

Site and Resource Planning

Site and resource planning1

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 managementstructure?

  • Where will the developers come from, be located, and what experience do they have?

Site and resource planning2

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?

Site and resource planning3

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!

The role of the software architect

Recipe for Disaster

Analysis Paralysis



Foundation for all systems cp one

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



  • 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



  • 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



Utilities for related systems

Utilities – For related systems

  • Utility Addresses

  • Utility College Master

  • Utility Standard Code Table(s)

  • Utility Degree Honors

  • Utility Department Master

  • Utility Degree Ranking



  • Utility Home Page

  • Utility High Schools

  • Utility School Master

  • Utility Term Control

  • Utility Term Dates

  • Utility University Master

The role of the software architect

Recipe for Disaster

Thinking any of the steps up to herecan be skipped.





  • 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?

The role of the software architect

Recipe for Disaster

Bad Primary Keys,

Data Structures,

and Principal Object Relationships

Floor work

Floor Work

Floor work1

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.

Floor work2

Floor Work

Don’t forget everything else taught in this Software Engineering course!!!

The role of the software architect

Recipe for Disaster

Watch out!

This is where specification creep can doom the project.





  • The executive management subsystem

  • Uses summary data from the other subsystems

  • Assesses the health of the organization

  • Identifies trends

  • Pinpoints potential problems





  • 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?



Renewal why

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

Renewal when

Renewal / When?



  • NormalizationDo It once

  • SequencingDo it in order

  • StandardsBe consistent

  • SupportYou can’t do it alone

  • Login