Solution Architect for Atlassian® – need or waste?

Solution Architect

Well, that’s my regular job title – Solution Architect. Actually – it is Solution Architect/Expert. I have c.a. 15 years of experience in IT, in ITSM field, 12 years of which were related to tools. Furthermore I am partly in Product/Service Design & Management, Social Media etc. After that short personal intro – a question: do You need a Solution Architect for Atlassian® Products? I could not answer other than “YES”. That’s obvious (Thank You, Captain Obvious). But why actually do companies using JIRA®, Confluence®, Bitbucket®, Bamboo®, HipChat™, SourceTree™ need Solution Architects?

Open platform is a curse

Well, it isn’t. If You know exactly what your needs are. But if  You think about all possible scenarios and all possible variables – what are the priorities? Fact that You can do ANYTHING does not mean that EVERYTHING will be done. Unlimited capabilities of Atlassian ecosystem can make decisions though. Which way should we go? How should we use it? How can we apply the platform to various cases? And so on, so on, so on… 

Cursed cases

Let me show You three cases from my work history – from different organizations:

  1. I was auditing JIRA – used for SW Dev, Project Management, IT Support – organization of around 3000 employees total, of which 200-300 have JIRA licenses applicable. 120+ issue types (60+ specific for ONE project), 200+ workflows, about 200 screens, 350 custom fields (average – 30 per Screen), hundreds of reports, dashboards etc. They reported JIRA is slow, users do not fill-in fields required for processing issues, they do not feel like having everything manageable, etc. And I had got reference point – organization of 5000+ employees, of which 3500 were JIRA users, and they had got <40 issue types, about 100 workflows, about 200 screens, <100 custom fields (average – 15 per screen). And most of feedback opinion were it is nice and easy, smooth etc. 
  2. Confluence used as a Knowledge Base for SD projects, and all the documentation under shared folders – this was use case to assess, if Confluence is cost effective. Well, in this case – it is not. But why don’t You use Confluence as documents library? Meetings minutes store, project docs repository, internal policies store – at the end of the day – THE INTRANET??? They never thought about it… 
  3. Due to some compliance issues Code review could not be done just as a markup – company required “formal process” with recorded “approval”. Of – please, bring me something more complicated – Do you have JIRA and Bitbucket/Stash? Yup, we have. So where’s the issue? Trigger, assignment, approval, webhook to push commit to working fork (or master). Or even to deploy changes via Bamboo (or any other solution).

When You have some experience with Atlassian tools – these cases seems simple. But apart from hands-on knowledge within tools, You would need some other skills. If You haven’t got them – Open Platform is a curse… And a trap.

A trap

If You can do anything – please do …. Oh, this is one of my favorites. Yup, I can. But the first question that Solution Architect should ask (and rarely App admin will do so) is: what is a need for that, and what is a value of that solution? Doing things just because You can is a total time and money waste. Of course You still can, but… 

The box…

A trap is also related to thinking “in” or “out” of the box. Thinking… Do not refer that to Atlassian’s products offerings “out of the box”. First lesson for JIRA I have had in the past was that You should be very open minded in meaning of “how to do it” – obvious for other platforms solutions were complex in JIRA, but on the other hand – there is always a simple way. In JIRA not always information equals field. It might also mean transition in a Workflow. And not always change is related to transition. Sometimes You just edit and update issue fields, what modifies information, but isn’t reflected in Workflow. 

Be green…

Another point is about recycling, or even up-cycling platform “items”: issue types, workflows, fields in JIRA, templates and blueprints in Confluence etc. Quite often requestors think “in the box” – I need “THIS”, where “THIS” is so specifically defined that will be one project specific. But with wider approach it may be reusable component – e.g. multi-user picker called “Team” in one project, might be used as “beneficiaries” in other, “required staff” in another, etc. Tasklists in Confluence might be used for various cases with checklists – not only for meeting notes, e.g. as a checklists what You should do when packing for Your business or personal trips.

Solution Architect vs Admin

I wrote above about things that Architect will do, and admin rarely does. And I assume this is a key point for having Solution Architect on-board. It does not mean that admin cannot play that role. But there are some differences:

  • Application admin is rather focusing on maintaining instance and helping users to solve daily issues – with logging in, with app’s performance etc. In some organizations with restricted approach he will also work on delivering projects, projects’ config or even dashboards etc. Admin is, in other words, delivering things requested by others to app users. 
  • Solution Architect is focusing on business value and platform capabilities vs. complexity of solution (e.g. to not allow to define too many issue types). His role is to know the solution well enough to define “how it should be done”. Architect will say – OK, that’s nice what You want from this app, but we will do  it slightly different, and here’s – how.

These two roles require slightly different approach and skillset. If person in Your organization managing Atlassian apps combines these two – it is perfectly fine. But, if for any reason – it is not a case, You need two people.