hello everybody today I'm gonna speak a little bit about the topic that
appears in sales that guys has risen and I would like to share some thoughts
on this the topic is the future is multi - stacked ok so agenda first we'll check out
what it means and why we will have a multi stacked future
what we need for that future to be good for us
and yeah let's see so first
okay can you change the slide ok
so first a short reminder from past presentation we shared the
screenshot of the old monolithic architecture that we had many years ago
and current state of the IT where we have much more layers and much more
technologies involved and this thing is appearing more and more often
and we need to take it into account in our daily operations
so future is multi stacked
we get new projects that use one of many front-end technologies
and one of many back-end technologies so that's the first change that we have related to it
another type of challenge that we have with future multi stack is
that sometimes there is a customer who comes and says that he will need
he will have multiple projects for us but in different technologies
the sales that we do right now are more related with the solutions that we provide
so we encourage more diversified systems that are already implemented
or CTOs that want to use particle technology
sometimes we can influence it sometimes we can't
and it's something that we need to get used to
of course
of course this this involves a big challenge because we can't
it's really a challenge to have that many technologies
and has a very deep understanding of each of it
it's also a challenge to have experience in many technologies
and it's enough to run those projects
so of course we can't specialize in every technology
so we can't specialize in React and Angular and Ember and Vue and Rails
and Elixir and Python and .Net and Java and Go and Kafka
we can't really specialize in everything
so what we will do and what is happening is that
we work with in this environment where there are multiple stacks but we work with other companies
and I think in the future it will became more and more in common use case
and we have to prepare for it be aware of it and try to do our best in this environment
so I think to prepare of it what we can do is to work on some
higher level elements of building the systems
so leadership and project management
that's a universal thing that we should try to be good at and to
provide value to customers in this area
we should also provide a good architecture and infrastructure support for our customers
and also help with building good APIs and UIs and for those systems
so first point
so leadership
leadership and project management this is very important topic
and by leadership I mean the overall leading of the project
so showing incentives and if something doesn't work well in the current system
try to come up with a better solution
if us and other vendor let's say we provide a front-end solution
and they are providing backend solution
it's important to try to lead it and make the cooperation productive
so we have some standards on it
try to share it show why it's important
and make the buy-in for the other side
in project management Simon and people from leadership team are working on best practices
I think it's good to know it because those are really simple things
that we can easily apply on every project like short stand up every day and a retro a proper backlog
quick learning that's also a very important area
so I think because we work with many more solutions
and we will need to learn more quickly
so the initiative recently with the workshop on every
Haxorz is one way to improve it
but there are many other things that we can do
so there is of course the shared repository where we share some some links but
nothing beats the real work so it's important to have a reference projects
in different technologies for example I'm making and building react reference
application where we try to work on best practices and if we pick up some new
solution that makes the code simpler we try to show it there and show to
customers and that we have the competency to actually and make
things simple and productive with our approach to it
of course we try to use as much open source inside of it as possible but also
it's important to make all the parties connect and this means not only the
front end but also the back end for it
specialized partners that's a very important point
a specialized partners it's something that we have in form of Softkraft for example
where they handle the big data part for us
and we handle the front end and configuration applications
so it's working quite well and I think in future
if we have for example a project where customer needs a back end in
.Net for example and we have a partner who is very good at .Net has
competency and experience it's good to continue the relationship with the
customer and work on a project even if we can't hand handle all of it so let's
say we cannot handle the back end so I think it's we should
try to shift our minds and to deliver value to the customer and still try to
work on those projects let's say if there's opportunity to work on let's say
a front end and part of it and have the company to do the .Net that's really
good it is especially important because if we work with different technologies
we can also try to especially with the same partner we can try to make a good
synergy with them so we can and build a good practice in let's say in React and
we can share it across multiple technologies and innovation
innovation is also important to try out new stuff
so when we have new challenges
we we should not say no to them because we haven't done it it's rather that we
should have open mind and try new approaches to solve problems
for example GraphQL is a new innovation
and that is happening at the moment and it's
a it's something that we should also learn and use on projects
next area of of improvement is an architecture and infrastructure
so I think what is important for us in context of working with more
complex tech stacks is that is a single page application which is separation of
the front-end and back-end code which makes us much more easy to work with
providers who have different backends another thing is that in the back end
systems themselves can be distributed or I can use micro services architecture
which means that they are in the internally also can have diversified
tech stacks this makes it also usually easier to migrate solutions and
try alternative technologies on the back end side the same with the front end if
some front end needs to be changed to a different technology often you don't
need to change the back end or the or the back end changes are small especially
if you have a standardized protocols on API big data and machine learning is
another thing that is important especially in terms of covering the
whole solution so even if we don't specialize in let's a Haboop for example
we still should understand how to get the stuff done the other partners
and what partner needs from us and let's say on the front end part
or on infrastructure or any other task
so that we can deliver the full value to customer
and server provisioning is also important because when you have like
multiple technologies you have to and be a little bit more better in setting up
the server environment it's not no longer a simple Capistrano task but
rather a little bit more complex setup
and often each service might require
different server or some libraries
so it's better to also have a good practice on managing that
API standards
and that's something also worth to mention that there are some existing standards
that are used in company and for example JSON API which is used by Ember
it's really nice to even through
on let's say on React we have choice much more choices
and it's not not that much that you by default have to go with JSON API
it's better to actually go by default with JSON API
because then it's easier to share solutions between projects
so the front-end code can more easily use the
same approach to handle resources, handle login handle roles on the back end
everything gets simpler so I think standardizing around those some
libraries is also good so when we go with GraphQL and one team goes with
GraphQL it's also good to think out in longer terms that we will try to
use it on other projects as well
so take your time to design stuff better
and I think it will benefit us and will benefit customer if we try to standardize on API points
finally the UIs
I think there are many libraries on the UI but what
is worth to mention that Bootstrap which we have been using or is used by
on many projects little bit old not so perfect but also there are new standards
approaching and one of the most exciting is a Material Design here you can see a
small demo of what material design can do so it allows you to make quite
nice interfaces not only on the web but also on the mobile where many
problems are already solved so imagine that you have to build this
whole thing custom code is a lot of effort and I think building on top of
already provided library that implements let's say this standard is better than
building everything from the ground of course it's a matter of discussion which
library we should use exactly but still I think using a library on two
projects or three is better than using a different custom solution on
three projects and have to manage that all
also I think overall using open source and supporting it
and makes it also very beneficial but I would like
you to start thinking about trying to unify it if you if you see some
opportunities on this talking to each other and discussing it
can we go next slide
so I have tried to collect some actions that we can do
so I think there are two important points
first one is to don't be afraid of learning new stuff
so take opportunities especially to do cross team learnings
and to learn on a new sales and new projects that approach so I gathered
some examples where someone didn't know a technology and learned it on a project
or experiment for customer around the area and it provided value for that
person for a customer and for us and because that person became better
or specially more expert in the area so I think it's very good that when you
learn new technology to try to pick up the technologies as close to what
customers need and we all the time we get questions for current customers
about some specialized area that they need someone might need another react
developer so you might want to train someone when we don't have one available
on the other hand someone might have a challenge in a project and that
challenge might be solved in other projects so it might be good to take the
developer to that project to share the knowledge and help to
speed up spreading the know-how
so I think it's it's really worth to
mention also sometimes some people like like me they work on one technology then
they switch to another and they switch to another and despite it might
mean crazy but once you learn or master a front-end technology on a
certain level when you switch to another one you reuse a lot of knowledge between
it so it's it's learning is important part of the process and I think it's
it's an opportunity and a challenge so I wanted to show some
examples so that you can see how you can more effectively do it another thing
is leading projects and making impact there so I think it's important to be
active in project development so not be passive cause a passive developer who
just waits for customer for example to define the backlog but try to work with
customer to make the backlog better maybe propose some some improvements to
it sometimes you might like me for example you might develop a certain
practice on one project for testing with say React components for example and you
might want to propagate it I wrote an article for example about that and I try
to encourage more people to use it
so that the testing is faster on the project and more predictable
it also is beneficial for the customer because
we have it's usually the practice that we try to build here our
productivity so the customer might not have tests because it
was time consuming and we've had proper practices it's it's a time efficient and productive
Błażej has introduced a JSON API instead of REST API
which had also some benefits and unified the code you could reuse some code
so it's all good examples of what's good
to do to improve this collaboration
that's it
For more infomation >> How is this frustating - Duration: 1:35:33. 
Không có nhận xét nào:
Đăng nhận xét