[Newbie] Roles required to implement and support Alfresco ECM

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

kincaid

We are primarily an infrastructure support company but an opportunity has arisen to get involved in Alfresco ECM (design, implementation and support). We are trying to map out the very high level roles required and I believe it looks something like this:

1. Architect
2. BPM
3. DBA
4. Middleware / configuration specialist
5. Product SME (could actually DBA or Middleware person)
6. ?

The question I have is (a) is it realistic to be able to support Alfresco without having developers in the picture (are the tools available out-of-the-box to allow you to build the front end screens or is it always a requirement to have pure development skills involved to get real value) and (b) are we missing other obvious skill areas (I am deliberately ignoring Project here as that obviously involves a whole other layer of skills).

Thanks,

Eddie

afaust

a) It is not realistic to support Alfresco without having developers in the picture, specifically if you are talking about designing and implementing solutions. There are no flashy UIs to help you build custom frontends, and especially now that Alfresco is focussing on the Application Development Framework (ADF) for custom UIs in the future, any 3rd party tools that may have existed are obsolete. You will need developers familiar with Angular alone for the frontend part, and you may want to have developers familiar with Java / JavaScript for backend logic, like automated rules, behaviours, actions etc.

The standard UI Alfresco currently has in the form of Share is essentially being EoL'ed, will be partially castrated in the 6.x release and only stick around as long as Alfresco still relies on it for its Records Management / Governance Services solution. It is no longer recommended to base new development on Alfresco Share, so in fact, there is currently no ready-to-use client that could even provide a simple "configure your UI" capability. And Alfresco has stated they are not interested in providing a replacement, ready-to-use client, instead having customers / partners build custom solutions using ADF (and minimalistic example / starter clients like the Alfresco Content Application / ACA or Alfresco Process Workspace / APW).

If you add the "Developer" role to your list, you could either have the separate roles "UI Developer" and "Backend Developer" ("one skillset code monkey" cliché), or a single role "Fullstack Developer" / "Developer" / "Software Engineer"

b) When you talk about Alfresco ECM (or Alfresco Content Services / ACS as it is currently being referred to), you could drop the BPM skill part of your list, since BPM is a currently considered to be a separate product (in fact, current workflow capabilities in ACS will very likely be removed in a 6.x release) called Alfresco Process Services / APS.

I don't really understand what you would group in the "Middleware / configuration specialist" category, because I would consider configuration of Alfresco to be part of the "Product SME" section.

Having DBA as a separate role is typically preferable, given how their special (vodoo) knowledge is often extremely tangential / irrelevant for the Alfresco use case - until some lone day in 5 years it actually is helpful in identifying an extremely obscure issue. The Architect / Product SME should have a good foundation level of abstract DB-related skills (including understanding query performance impacts, analysis and optimisations) to be effective within your team without having to tap into specialist knowledge. The DBA's job then should (typically) only be to make sure the DB runs smoothely, completely oblivious to what application uses it...

In most of my Alfresco projects, the team was usually not that large that separate roles could be maintained, so everyone needed to be a bit of everything. Most of the time, the customer insisted on DBA skill being provided by their centralised DB department / team, which - 99% of the time - underperformed and was more of a hindrance then a pool of "specialists".