How Would You Reorganize An Application Service Delivery Model?

 it service management, management  No Responses »
Mar 202010
 

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.

Corporate Information … single source or single search?

 enterprise architecture  No Responses »
Jun 032009
 

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.

What good looks like … follow-up

 enterprise architecture  3 Responses »
May 252009
 

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
 Older Entries  Newer Entries

Switch to our mobile site