he discussions I had with the major IT companies in Cluj, at the beginning of 2017, focused on their predictions for the current year. Aside from the fact that all of them predict a substantial growth in the Romanian IT sector via the development of services, products and training, each has a unique way of forging their path according to the goals at hand.

We have over the last 12 months starting to look extensively in how we can leverage AI / Deep Learning to help improve OpenStreetMap and today we want to provide a few details about how we envision the future of making maps and also share more on what we are already doing. We see the emergence of self-driving vehicles as a game-changer and one key requirement for those vehicles are accurate and up-to-date maps. Currently commercial map providers map every region around every 12-24 months – in a costly process with a high precision and high cost vehicle, our goal was to achieve maps that are updated on a minutely basis and with key streets covered at least once every day. This is the goal we set out to solve with OSM in supporting to make it ready for this use-case.

You’re starting a website. How should you go about it? Is a Content Management System (CMS) necessary or even worth it? There’s a lot of mutually opposed and inconsistent information on the subject and truth be told, there’s no definitive answer to these questions. There are very pertinent pros and cons for going with or without a CMS. This article is not an exhaustive presentation on the matter, nor does it try to come with final answers. It’s a simple depiction of a feasible alternative to the plethora of similar solutions out there.

There are many times when starting a new project as a monolith makes sense, especially in very lean projects where the requirements and the product are not entirely clear from the beginning. In such a project, the domain and domain models shift and change a lot as the application pivots, and the requirements evolve. As the project and product mature, hopefully, their domain takes shape and settles, becoming more stable. By now, some parts of the domain will be more active than others. This is the stage where micro services bring advantages, allowing the development teams to focus on smaller areas that are more manageable, easier to handle, test, and deploy. But that aspect also adds a bit of overhead as all these different domains require focus to integrate and automate. At the beginning of a project, almost all areas of the application evolve requiring continuous integrations and deployments. At that moment, there is no real benefit in splitting them. Considering that the requirements might be too fragile and, as a result, the domain model of the application might be quite volatile, micro services add to the overhead, as some may disappear or shift considerably.

Architecture description languages (ADLs) are formal languages that can be used to represent the architecture of a software-intensive system. As architecture becomes a dominating theme in large system development, methods for unambiguously specifying architecture will become indispensable. By architecture, we mean the components that comprise a system, the behavioral specifications for those components, and the patterns and mechanisms for interactions among them. Note that a single system is usually composed of more than one type of component: modules, tasks, functions, etc. An architecture can choose the type of component most appropriate or informative to show, or it can include multiple views of the same system, each illustrating different componentry.

This article aims at answering a set of core questions about software architecture, providing answers that come from modern software architecture thinking. Its inspiration came from:

• Conversations with Rebecca Wirfs-Brock and Simon Brown
• Architecting the eventrix.co product, running “Architectural Katas”
• Countless conversations with architects and developers at international conferences
• Conversations with participants to architecture workshops

The beginning of the year and various other occasions mark the opportunity to wish each other good health. Health is most important for many of us. So, why wouldn’t it be important for the business environment as well? Why shouldn’t our organizations also aspire to good health? This is even more relevant since we spend more than a third of our day (out of the time we are awake) at work; and, let’s face it, our involvement with our work goes beyond working hours, stretching in our free time as well. Since the organizations we work for occupy such a great deal of our time, I cannot imagine any HR person, any team lead, any manager or person who wouldn’t like to work in a healthy organization. I think we can all guess the answer to this one.

The startup world is getting active in the new year. Here you have a few options for the upcoming two months:

Startups are changing the world we live in. This was clearly the message of last year’s tech media, both the Romanian and the international one. But do we know what these so-called startups we hear about every single day really are? Although there are lots of definitions for a startup, some of them very technical, others rather bohemian, there isn’t one that’s unanimously accepted. About 2 years ago, Alex Wilhelm made up a ”50, 100, 500” rule.

I often see technical people who offer a solution too quickly, instead of “wasting time” with questions which might help identify certain needs. Then, developers feel offended because their wonderful solution is not embraced by decision-makers for the mere reason that they simply do not understand it – or so they claim. If they rush to come up with a solution, someone (even if they are developers) should spend time to identify the needs of those involved in the decisional process. There may be one or more who have different interests.

Wouldn't it be wonderful if there were a standard for evaluating design deliverables? It would make everyone’s life easier: designers, project managers, clients. Good-bye complicated discussions! Well, even if there is no magical formula, this article gives an overview of criteria that help to evaluate digital design deliverables. The way people relate to design can make the process of digital product creation difficult. Design seems to be subjective and esoteric. Further, some people believe the myth that having seen many designs makes them experts. In reality there are empirical and pragmatic principles that form the basis of good design.

In the previous issue, we introduced the performance management framework OKR (Objectives and Key Results) and how it can help us build and grow performant product teams. In short, OKR is a set of measurable objectives and key results that we set quarterly. Each objective has a responsible, and at the end of each quarter we draw the line and evaluate the results: how many goals we were able to accomplish? Next, we will consider a timeline for implementation of OKR in a company, with a snapshot of annual and monthly activities.