First off, thanks for tuning in to the first of hopefully a long list of meaningful and helpful blogs published by EV Technologies. Each week we are going to strive to publish a new article aimed at the use of some facet of the suite of Business Objects tools.
So…here we go!
A few years ago I responded to a forum post on BOB, which asked how to estimate the size of a Business Objects support team. That was over three years ago. I was actually asked this question again here recently and I thought it’d be a good idea to revisit this topic.
BI Architect – I’m really not starting there because I’m partial to this role J BI Architects play a pivotal role in how an organization deploys and uses Business Objects. This role should be responsible for defining how the architecture is defined, defining company standards regarding the usage of the product, can mentor or lead other development resources, and can serve as a liaison to other technical leads. An individual in this role should also not be afraid to meet with executive level persons in an organization to understand the needs of the business and use that knowledge to anticipate needed shifts in BI strategy. Some characteristics to look for in a BI architect may include things like a long history with the vendor, a deeper breadth of knowledge across all the products in the suite, understanding of IT principles outside the BI space (web application architecture, database architecture, infrastructure, and more), and a history in being on the development side of this product suite.
Team Lead/Project Manager – I’ve been a part of a number of different team structures, such as centralized development and matrixed organizations. I’m not advocating either structure. Regardless of team structure, a strong Team Lead or Project Manger is a pivotal role in ensuring the success of a team like this. This person doesn’t necessarily need to be a Business Objects expert, but should be familiar enough in BI principals and how a BI team relates to other parts of the organization (particularly database/data warehousing and ETL), that they can help to guide their team members through the processes of their organization. This person should also drive the project plan as well. Whether using agile methodologies or plain old waterfall approaches to development, have a published plan that each team member can follow. It’s important that everyone gets the expectations placed upon them.
Universe/Report Developer – At the risk of sounding redundant, this is the million-dollar question. I’ve met so many people that are really good at universe development, or report development, or both. Now these roles are even further complicated by the introduction of Crystal Reports and Xcelsius to the stack. That said, put a Universe Developer at the top of the food chain. The Semantic Layer should be the underpinnings of all of these development tools. Having a strong Universe Developer means that each of these technologies has a strong foundation for future development. Strong Business Analyst skills coupled with strong Universe Development are the key.
This blog post doesn’t attempt to peel apart the smelly onion…whether to use Crystal Reports, Desktop Intelligence, or Web Intelligence. Perhaps that’s a post for another day. Either way, ensure that you have strong resources in the desired technology.
The burning question now may be “how many resources?” Pretty much word for word from my prior post on BOB: Sure, you could have one guy per 25 universes. But what is the activity on each of those universes? Will they all have changes monthly or annually? This will be the hardest to pin down. You just have to decide how complex your universes are, and how long each change (new object, condition, etc) takes to code and test (say 15 minutes per object, code and test). Then decide how many changes per day you have to make based on the universes and projects you have. The same holds true for reports…it all depends on their complexity and how many changes per week/month/etc. The largest team I ever had was twelve people maintaining about 30 actively maintained and evolving universes, and about 100 reports….and they were busy constantly, and all were quite talented.
Xcelsius developers are really in a class of their own now. This is an emerging technology believe it or not. There aren’t a large number of folks that know it extremely well. But those that can build well performing, visually appealing dashboards (in executive eyes) will be successful. Also consider getting involved with a graphics artist. Xcelsius is pretty, but getting an outside opinion on enhancing the look and feel of the dashboard, outside the canned styles including with Xcelsius, will bring a unique flare to an executive dashboard.
SDK Guy – I love these guys. I love application development. Having a strong Java/.NET developer that knows the Business Objects suite of products is awesome. It’s a highly customizable platform…thus the reason EV Technologies works hard to deliver quality integration products. If you feel like you regularly customize, it’s a good idea to have a strong programmer on hand. While this may be a “frill”, it may be better to build a strong relationship with your web development team in your company. Many times a project may fund that development, which will help pool the experts in your organization to get some internal help for that work.
Infrastructure Admin – I’ve worked this both ways, with dedicated infrastructure administrators as well as shared services, like Windows/Unix Admins. Personally, I believe at least one dedicated Business Objects Enterprise admin is a must. Depending on the size of your organization, maybe more (but not likely). It’s tough to get the attention you need from a platform perspective when you have someone with shared responsibilities like this that may not be able to devote the time and energy to maintaining the Business Objects platform.
Center of Excellence/Competency Center – This is still a creature that is evolving as BI matures in organizations today. In many cases this group of individuals may be a stand-alone organization. There are tons of white papers and guides with best practices on building these types of organizations, so I won’t step into that today. However, ensure that someone on the team, particularly the architect or team lead, has a strong relationship with this group of individuals.
So that’s it. The reality we all face is budgets. Obviously, this isn’t a science either. Building a strong Business Objects team takes time and sometimes, iterations based on the ever-evolving needs of the business. Hopefully these concepts can help in establishing some selection criteria when the opportunity presents itself to build a team.