Posted by Leo de Sousa on April 27, 2010
SGHE Summit – Project Horizon Technical Overview – Bob Rullo (@bobrullo)
* power in Moscone West went out just as Bob started his talk. He did a great job working through his presentation with no slides! Great job, Bob!
SGHE Summit – Project Horizon Technical Overview
- needs Oracle 11gR1 database, Oracle Weblogics App Server, Java 6, Grails 1.1
- moving from Banner INB forms to new Horizon (Aurora UI) architecture
- need to migrate CRUD and transaction validation, field level validation (UI centric validation)
Grails Architecture
- a controller handles requests and talks to services to provide a response (data back to the user)
- blocks and fields map to the domain model like a row in a relational table
- field level validation moves to the view as do the canvases and windows – AJAX based
- leveraging automation techniques – by gathering metadata in the Banner Db and create a domain object
- can generate 80 to 90% of the domain models with these tools
- services are also being generated as well as the UI – where are fields located and how do we navigate between them
- we will be allowed access to these automation tools for our custom code and modifications
- look at providing us preview releases to get familiar on how things work and provide feedback to SGHE
- test early and often approach – huge increase in unit tests 100 to over 1000 = better quality
- our people need to learn GRAILS, java, groovy skills as well as spring and hibernate, still using PL/SQL apis
** SGHE please provide us a VM spec for a sample sandbox application
Resource Oriented Architecture – RESTful architecture allows us to extend our Open Digital Campus
More sessions …IT Lounge on Tuesday at 4pm
Posted by Leo de Sousa on March 20, 2010
I have been thinking a lot about re-engineering the service delivery model for the application services team that I lead. I have been guiding my team to think about:
“We deliver the platform and work with the business to provide services”.
Our applications team is made up of subgroups aligned by major application services. Here are the major applications:
- Business Intelligence
- Collaboration Tools
- Document Management
- Email and Calendaring
- ERP (Student, Finance, HR, Doc Mgmt)
- Identity Management
- Learning Management Applications
- Microsoft Applications
- Oracle Database
- Portal (for students and employees)
- SQL Server Database
Currently, there are 3 teams in place in our Business Application Services group. Here are the roles in each team:
Support Team
- Oracle DBA
- Document Management
- Business Intelligence
- Project Management
- Business Analysis
- Identity Management
Email and Collaboration Team
- Email
- Calendaring
- Instant Messaging
- Collaboration Platforms
- SQL Server DBA
- Microsoft Applications
- Enterprise Portal
Developer Team
- Oracle Developers
- Lotus Domino Developers
- Microsoft Developers
- Java/Web Services Developers
I am interested in hearing from any of you that lead groups with similar responsibilities. Do you have a suggested structure for me to consider? Do you split your team based on roles (technology domains) or by application (vendor) platforms? Do you split operational work from project delivery? Does your governance structure influence your teams organization?
Any suggestions are very welcome and I hope to learn from some of your experiences. Thanks in advance.
Posted by Leo de Sousa on June 3, 2009
Recently, we have been talking about creating a single repository for IT Services departmental information. The idea being that our team members need to go to one place to get the information they are looking for. Instead of wasting time looking at multiple repositories each with their own taxonomies, UX and search features, put it all in one place with one UX and taxonomy.
Today, my thinking took a 180 degree turn with a vendor presentation on “enterprise search“. Instead of making people conform to rigid rules about where to put information, what if we gave them a tool to find the data wherever it resides behind our firewalls? Like someone said today, “Google search for our stuff”
No some of you might say, not taking time to architect an information repository and relying on a search engine is the lazy way out. I have some thoughts that I hope will make you think otherwise. When presented with business challenges, I find it is rarely the technology that is the problem. Instead, it is the ease of use for our clients, customers and stakeholders that should be considered. Enforcing compliance is expensive and in many cases ineffective. What if we made it easy for people to comply? Educate them on some simple tagging and then let them work like they always have. The difference is giving them a tool to search for what they need and work to tune that tool so that we see a significant reduction is costly “Search and not find” scenarios.
I will now begin some research on enterprise search and report back later. Have any of you implemented an enterprise search capability? What do you use?
Here are some links:
Looking forward to hearing your thoughts.