Electronic Banner Access Request (eBAR) Workflow – Portland State University

Replace paper form routing from Portland State University

Electronic routing – replaced two paper forms with Banner Self Service online form – uses Banner Workflow to route the request

Advantages of eBAR Workflows

• faster than paper request process
• can be routed to multiple users in parallel
• no time wasted delivering paper between offices
• no lost paper forms
• password delivery via BSS = security
• copy permissions from an existing user
• “I Agree” checkbox for Acceptable Use Policy
• dynamically routes to supervisor (right now user picks their supervisor)
• auto creates workflow account for supervisor
• supervisors can assign any workflow user as proxy
• created a way to determine segregation of duties when applying Banner user classes and in particular objects (requester must explain why they are requesting access that violates the segregation of duty conflicts)

Business Decisions

• Authn
  • Banner INB
  • Enterprise LDAP
• user creation
  • used workflow

Workflow Setup

• workflows can not span orgns but a workflow can initiate a workflow in another orgn
• TIP – design your workflow around your orgn not around Banner modules

Roles

• System Administrators = IT Staff
• Business Analysts = IT Staff, Banner Coordinators
• Request Approvers = supervisors
• HR Employee = Human Resources staff
• Banner Coordinators
• Business Affairs Director
• Account Creator = DBA
• eBAR Admin

Demo … run through Banner Self Service and Banner Workflow

Challenges

• modeler hangs when trying to validate model – had to reduce the number of activities in the model by moving processing to dB procedures, save results in temp tables, etc
• mapping external event parameters to workflow model – load all 30 parameters into a temp table before event fires, map one parm  to find others
• using javascript in custom activities – use a dbproc to gen javascript
• custom activity forms are very limited – create a custom activity with only a few text areas, use a dbproc and javascript to create the functionality

Lessons Learned

• design for easy maintenance – making changes to the Workflow model can be tedious – put as much into dbprocs to keep model simple
• design for user friendliness – generate HTML view to display over the Workflow form, use drop down menus and checkboxes, dynamically create these menus and checkboxes

This is my review of this morning’s Architecture & Governance magazine webinar ”The State of EA: Is 2010 the Transformational Year?”

Presenters:

• George Paras, Editor-in-Chief, A&G, Managing Director, EAdirections – gparas@EAdirections.com
• Alex Cullen, Vice President, Research Director, Enterprise Architecture, Forrester Research – acullen@forrester.com

1. What is the current state of EA? Forrester conducted a survey of 416 IT professionals and found the following:

• Increasing awareness and acceptance of EA – this is change in that there is much more broad support for EA as a discipline in organizations
• EA teams are part of senior IT management – more focus at a senior level instead of a tactical level in IT (* true in my case moving from a staff EA position to a management EA position)
• Primary drivers for EA programs 1) better strategic planning 2) consolidation of technology 3) improve business agility4) enable business-IT alignment
• Infrastructure, Security and Application architectures are the most complete, next Integration and Information architecture are underway and business architecture is the least complete
• Where to architecture groups spend their time 1/2 time spent on non-project activities – supporting enterprise planning, strategic planning, collaborating with business and governance
• CIOs look for EA to address their priorities – and guide and staff their EA teams accordingly – strongest technical thinkers, best problem solvers on EA team, business application area as EA lead

2. The Transformation of EA  Read more...

• IT expectations for architecture vary across 2 dimensions – Project to Strategy (Focus dimension) and Technology to Business (Orientation dimension)
• Derived a 2 x 2 model – Project/Business = Business solution architecture, Strategy/Business = Business and IT strategy, planning and alignment, Project/Technology = Infrastructure and application platform selection, Technology/Strategy = Technology and infrastructure strategy and roadmapping
• EA provides the most value when it is strategic and business focused but must overcome expectation barriers that EA is only about technology
• Business focused EA should mean more business awareness, acceptance and support – more work to be done with lines of business and corporate management
• Only 13% of corporate management actively supports EA vs 66% of CIO/Head of IT (* Is this a job for the CIO to educate their C-level peers?)
• The correlation between business engagement and Business Architecture programs for improving support for EA in organizations – almost double the support from the business

Alan Inglis posted about What good looks like from a solutions architecture perspective.  How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.

Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:

1. Project Background
2. Terminology
3. Key Drivers, Principles, Standards and Constraints
4. Business Problem
5. Information View
6. Risk View
7. Application View
8. Data View
9. Integration View
10. Infrastructure View

I have some questions for Alan on this:

• How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
• Is there a subset of these artefacts that would be sufficient for small and medium projects?
• How would the next solutions architect find and assess the artefacts created?  Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?

We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it.  Some of the key factors for me would be:

• ensuring that there is time for solution architects and enterprise architects to work together to do peer reviews: 1) pre-project, 2) technical reviews in a project and 3) post-project
• communication of agreed upon standards and principles is essential to build a common language
• negotiating with functional managers to ensure time is allocated to every project for architecture
• regularly demonstrating value to the organization by taking an enterprise, long term view