motivatie 2019 10 11 Tractebel

data team = software tea intern voor Tractebel

====================== motivatie ======================

ar de rol van release coordinator - data gedeelte , ik ben zeer goed thuis in versie beheer tools ( zoals subversion , in mindere mate git )

        ( geen Oracle , Teradata of DB2 oplossing , wegens eenvoudiger in opzetten en betere integraties )

Daarnaast kan ik makkelijk switchen tussen de grote lijnen en praktische details, wat mij voor architect van groot belang lijkt,
( tevens uit mijn opleiding geschiedenis de vaardigheid geleerd om cases op kleine schaal te plaatsen in een groter verhaal, en omgkeerd . )

Letter of Motivation.

Following elements from this exciting and broad vacancy seem decisive to me :

Someone with goood experience in IT processes and standardization
Someone who can think about and give input about architecture, the direction to go with IT solutions.
Someone who can act as a bridge between different teams & departments.
F.i. between developers and architects, between buisness and IT, between technical people and managment.

Below are just some examples to illustrate why I am convinced to be a fine candidate for this function.

1.
Good IT policies & best opratices ensure more efficient working flow and less risks be taken.
Working experience in several large scale companies & multinationals has thought me the vital importance of having a good balancce between
ensuring professional IT procedures & practices are kept but not killing creativity or inhibit any initiative by being way too burocratic.
I have seen balanced approches (@ Getronics) but also organizations doing it in either one of the unbalanced ends.

As IT operations team manager with Transics, I implimented a change proces.
( any IT alteration had to be logged & approved first)
I also introduced a daily “sprint” meeting, first thing in the morning
( the idea taken from scrum , but
I negotiated and started the outsourcing of basic IT opertions needs ( basiccaly the 24/7 stuff )
with an Indian offshore company Cybage (https://www.cybage.com)
Knowledge transfer and implimentation of had to be discussed and implimented.
Working in the database development team with DePost IT, I was responsible for the release coordination for the database changes.
As a developer at the time, I needed to tune with project/release managment and with operations.
I studied parts of the official ITIL (IT proces management framework) guides.
This shows my deep interrest in this matter.
Many years of experience with source code versionning

2.
Although not as a architect, I have solid working experience with architecture.
- Getronics : I was member of the Datacenter Infrastucture & Architecture team, one of my tasks was data(base) architecture
- DePost IT : I was member of the Database architecture board
- Axa Bank Belgium :
- I made the complete design for the infrastructure (mixed cloud & on prem) and usage for PowerBI ( which I also implimented )
- the ABB architect team approved my recommendations about data encryprions , as for databases to not use the company tooling,
but to standardize on using the MS Sql server TDE solution
- Transics : I pushed to convert a good part of the relationele data (ms sql server) owards non-relational data (mongodb & redis databases)
(considering the advantages of beter scalability versus less strict data consitencies )
- I can easily switch between the big picture and the small scale detail, between the theoretical & the practical realities.
( that may be also due to my historical eduction where placing cases in a bigger context is a crucial abilty )
I noticed that more then one architects tend to “get stuck” in the theorectical.

3.
As can be seen in my resume, I have performed many different roles,
system engineer, help desk and support,software developper, analyst, team lead
I know first hand the diffenent ways of reasoning and looking at things of these groups, that makes it easy “to translate”

My relations with buiness users have alwaysbeen good.
When I left Axa Bank, several buisness people came to me expressing their worry
“with you, at least we could talk, and get a solution some way or another,you are not the typical IT nerd”
( I believe I can get referrencs for that, if needed)
I worked at large scales companies with many nationalities working together, that also demands translations.

Perhaps a final remak.
There is a certain ‘undefinedness’ in the job description, which I find stimulating.
It means there is room for creativity and interpreting to make the job better

====================== Plan van aanpak. ======================

Draft for a plan of first actions – Data Team Tractebel.

Meet the team members
Get the input the team on topics 3 & 4.
Get a solid picture & inventary :
what are the categories of IT tasks that are demanded from the team.
List the current workflows, the needs for change & their priorities.
Which procedures are followed, what conventions exist with the other teams.
What software & admin tools are currently used, internaly in team & externaly with other departments.
Does such an inventary exist or should it be made.
Dependencies on other teams and company.
etc.
From these information determine the ‘to-be’ situation.
What processes ( bug tracking, backlog managment, releases, agile procedure etc) must be kept or improved, changed or implimented.
What the tools be kept, removed or newly used.
( Under rougly simular conditions, open source tool should be prefereed, if they have a proven track record of wide usage.)
From the interview, it appeared that a solid ticket systeem -Jira is preferred- would the most urgent need.
To be used both for bug tracking and supporting the agile way of working.
( Jira is solid in these, I used it in several envirronments )

Below is when a scenario with Jira is choosen, with can be adapted.

Determine if a cloud version is possible (Jira = yes) for ease of maintenace/ management.
( perhaps on prem versions might be required due to demands by other teams or company contraints )
Get pricing & external support conditions & details.
Is there already a ticket, backlog , scrum-or-kabban system in place ?
If yes :
? migrate old data to Jira , if yes make plan for that.
? side by side usage for a period of time, or new actions/data only in Jira
Jira is quite “self-explaining” for IT people, still,
see if “getting started sessions” / training / online tutorials are required
Dicuss wether customizing the applications is needed (such as custom views, extra categories, etc)
Personally, I believe this should be avoided as much as possible, but sometimes there is no choice.
If needed, who will be doing these ?
Dicuss who (one or more) members -or myself- will be assuming the ‘Jira admin’ role