Multidisciplinary project emerges when multiple teams with different expertise areas join to create a product. Despite the fact the product development is not something happining merely my a wish, product leads often perceive it as an easy walk. Usually this easy walk becomes a crash course. Let's uncover what leads to crash and what is necessary to succeed.
Task: To provide automation for transfer of large number of files.
Source - computer with autotest codebase.
Receiver - gateway for industrial data processing.
Test receiver - second PC with installed vsftpd service.
As a product owner, it is common to face the question of whether to proceed with option A or option B. Or, which version of the screen should be implemented to achieve better results? Making such decisions can be challenging, especially when you are under tight deadlines with limited resources. Furthermore, such decisions are made based on personal judgment or copying the approach of a competitor, which can lead to suboptimal results.
The good news is that one can avoid such pitfalls by setting up a simple experiment environment that requires relatively low effort. In this article, we will describe how you can achieve this.
Creating a product startup can be an exciting experience, but it can be a daunting one as well. On average, only 1 out of 10 startups is successful, according to the Global Startup Ecosystem Report. Therefore, to raise your prospects, there are quite a number of important considerations to make in advance.
Bearing in mind everything you need when launching a startup is a challenging task, so it’d be a sound idea to rely on some well-established methodology. That's why we were inspired by the Systems Engineering methodology, presented in such industry standards as ISO 15288 and CFR21. In this article, we’ll make a brief overview of this methodology and highlight how it can help entrepreneurs to encompass and structure the process of creating and developing a startup.
This is a set of chapters for young engineers. We give practical advice and discuss goals, challenges and approaches used in modern software engineering.
Along with classical foundations this article contains original ideas of conceptualizing engineer's work with emphasis on bringing order to the situation and finding an insight. Engineering is approached as work in uncertainty with other people which requires special skills. Non-obvious complications regarding modern production in big companies are discussed.
This article is based on 15 years of experience in engineering and management in high-tech industries.
This is the translation of my speech at T-Meetup: DevOps Life Cycle.
I believe that you have heard about SDLC (Systems development life cycle). Is it possible that the same things are applicable for the IaC?
The step has been made. Not sure where to, but for sure from the point of no return. Keep calm and keep walking. It is about time to look around and understand the smelly and slippery route before you. And what are those noisy creatures swarming around our fishy “innovative” design we called Mandelbrot blueprint? You don't get a buzzing noise like that, just buzzing and buzzing, without its meaning something.
Architect. This word sounds so mysterious. So mysterious that to understand it you are almost forced to add something. Like “System Architect” or “Program Architect”. Such an addition does not make it clearer, but for sure adds weight to the title. Now you know – that’s some serious guy! I prefer to make undoubtful and around 10 years ago added to my email signature “Enterprise Architect of Information Systems”. It’s a powerful perk. Like “Chosen One”. With architects it is always the matter of naming, you know. Maybe that is why the only way to become an architect is to be named as one by others. Like with vampires. One of them has to byte you! That is probably the easiest way to earn the title as there is no degree or school to grant you one. And if there’s a troubling title, somebody’s making a trouble, and the only reason for making a trouble that I know of is because you’re an Enterprise. Huge old and complex multinational corporation. Like a one-legged pirate. Strong and scary, but not a good runner. You own your ship, you had good days, you have some gold, you need new ways.
To get to new treasures and avoid losing the second leg to piranha regulators and local business sharks swarming waters near every enterprise ship – every pirate has a map. A map is a list of major features and requirements in desired order and priority.
Before we start, I'd like to get on the same page with you. So, could you please answer? How much time will it take to:
It will take longer than you expect. I will explain why.
There was a custom configuration management solution.
I would like to share the story about a project. The project used to use a custom configuration management solution. Migration lasted 18 months. You can ask me 'Why?'. There are some answers below about changing processes, agreements and workflows.
It is the translation of my speech at DevOps-40 2020-03-18:
After the second commit, each code becomes legacy. It happens because the original ideas do not meet actual requirements for the system. It is not bad or good thing. It is the nature of infrastructure & agreements between people. Refactoring should align requirements & actual state. Let me call it Infrastructure as Code refactoring.
