How to find out if your idea is crazy good, or just crazy…
“No battleplan ever survives contact with the enemy,” Helmuth von Moltke, nineteenth-century innovator and Prussian Field Marshal, once said (in a more verbose German formulation*). One consequence of his statement is: If you don’t bet, you can’t play; and if you don’t play, you can’t know if you’ll win or lose. … Continue reading
Let’s Get to Know Each Other Better.
Sclable has built a “culture of doing” for itself and for its many satisfied clients. And we’re always looking for opportunities to share this culture with new acquaintances and get feedback from old friends. So we wanted to remind everyone this holiday season that we hold open office hours every Wednesday from 4:00 to 6:00 pm. … Continue reading
An Austrian Thanksgiving
While, on 24 November, America ate its way to turkey-induced torpor, Martin Sirlinger extolled the virtues of staying nimble: “Vienna, all of Austria in fact, is a great place for rapid digital innovation,” said Sirlinger, “already you can see a vanguard of agile companies, small and large, rolling out truly innovative digital transformation programs. It is our job to let the rest of the world know about the great things happening here.” … Continue reading
Watch your digital business idea evolve
… Continue reading
Mapping a Self-understanding
The difference between a tech start-up and an established tech company is a well-defined, executable Roadmap. … Continue reading
Crisper, Clearer Images Across all viewport Sizes
The specification of the picture element is the result of intensive research and development. It allows frontend developers to reference a set of pictures with different technical characteristics to display clear, crisp images across all pixel densities and viewport sizes. (I already gave a short introduction to the problem of different pixel densities in my last blog post.) … Continue reading
Sclable’s New Berlin Offices open more possibilities
Like Vienna, Berlin is one of the best cities in the world for innovation. (The Melbourne innovation agency 2thinknow ranks them #3 and #14 globally.) Young, growing start-ups gravitate to Berlin for the following reasons. … Continue reading
The following tips will help frontend designers create graphics that work on Android and iOS platforms as well as on other displays/devices that have differing pixel densities. … Continue reading
CIOs nowadays face the challenge of providing solutions that need to fulfill opposing requirements: on one hand, IT solutions must meet the highest standards in terms of security and reliability. On the other hand, agility is required during development as well as during ongoing operations.
This issue is not new, but has been discussed more intensely under the term “Bimodal IT” since mid-2014. The first strategy (mode 1) describes solutions for the company’s core processes. These processes emphasize security and reliability. The development cycles are described as traditional and sequential.
The second strategy (mode 2) describes applications that demand a high degree of agility and fast results. During development as well, as during ongoing operations. We usually associate mode 2 with the usage of current web-technologies, cloud solutions and disruptive technologies in enterprise-IT.
This article has first been published on LinkedIn.
Meeting with opposition?
However, as regards enterprise software development, this view describes only two extremes that are rarely so clearly defined. In fact, the requirements’ profile of most business applications covers a wide area of the tension between agility and stability.
Increasing process dynamics
Topics such as “compliance” and “regulations” have reached almost all sectors of industry by now. Deadlines associated with regulations often do not allow a timely adaptation of the company’s core systems. On top of this, global technological changes have created user-needs for mobility and device independency.
The demands on corporate-IT are therefore:
- Providing new functionality to add to core systems in a timely manner
- Rapid adaptation of functionality without compromising existing solutions
Whether it is because of legal requirements, market pressure or competition: Lehman’s first law of software-evolution is more valid than ever: applications need to be adapted continuously, or they become less and less satisfying.
Agile and business-critical
For departments such as sales or customer relationship management, the use of standard software can mean losing competitiveness. In these areas, solutions are often pushed by the employees of the departments, sometimes even by bypassing corporate-IT.
The complete range of concessions this causes in terms of security, stability and data-integrity caused by this practice, is often only recognized during ongoing operations.
Corporate-IT faces the following challenges:
- Integrate department employees in the application development process
- Rapidly provide user-oriented solutions to avoid shadow-IT
Usually, requirements differ not only from project to project, but also from project phase to project phase: until the first test version, a rapid implementation is important. While speed is the priority in this phase, reliability is what matters significantly from the first use of the productive system on. During the roll-out of new versions, a systematic guarantee of data-integrity is key.
The key factors in new IT projects are:
- Provide a highly adaptable and at the same time solid system architecture
- Connect to core systems taking account of all given regulations
CIOs and CTOs need to take the role as innovation leaders in corporate structures. It is their responsibility to watch current technologies closely and to identify solutions. The decision is hardly ever one that is biased towards either agility or stability.
What at first sight seems to be the task of simply “adding” a little agility to some specific projects, while leaving the existing IT landscape untouched, can turn out to be quite a journey as any agile coach can tell you. Our partner ANECON has laid out what it takes to identify and overcome the obstacles along that journey.
The same is true for the development technology stack. Building upon what you have might keep even your most agile projects in mode 1. If you need to consider both stability and agility or you need to consider varying speeds in different project phases, Sclable might be right for you. The Sclable Platform is designed to focus on security and reliability, while providing utmost freedom of choice for your application’s development technology stack.
DDD itself is such a huge field that I feel it is hard to get something to work without sharing experiences. One of my tasks here at Sclable was to design and implement a DVC (domain view controller) Framework in PHP. In this blog post I’d like to give you some insights on my findings over the last year. I just recently put together some slides for a talk at the PHP Meetup in Munich. The event was overbooked, so this post is also for everyone who wanted to join and couldn’t make it.
Before going into details I have to make a restriction regarding the type of software projects I am talking about. Since at Sclable we are specialized in business applications, I am not talking about production plant automatisation for example (just another field I have experience in). What I mean by business applications is quite the same what Martin Fowler means by his term “Enterprise Applications”.
Clear Your Concepts Before You Start
Mahmud Hasan, a software engineer from Bangladesh has got some slides for a good introduction online as I feel. So for the “What the heck is DDD?” part of my talk I am referencing his presentation – though I’ve never had the chance to see or hear it. I won’t go much into detail about DDD. Rather I’d like to show you, what is possible with PHP once you have a domain model. (If you want to skip the conceptual part, go right to the end of this post…)
The Traditional Way
DDD advocates are not saying that NOT doing DDD is wrong. This would be plain stupid as it really depends on the nature of your software project. There is nothing wrong with reading specifications, defining functionalities and features, estimating ressources, breaking down and distributing tasks, designing a database schema and finally: start coding.
Such software projects can be as successful as any DDD based software project. No matter if you are using an agile or classical development method. But after the first production release you might realize that your team is not doing so well in maintaining or extending the software.
That is where DDD comes into play. Instead of a bottom-up fashion DDD supports lean and agile software development in a way that you can iterate more often, still delivering results with every iteration. That is especially helpful if there is not a single person within the software project team that can fully grasp the business domain. DDD is a way of thinking that allows you to “tackle complexity in the heart of software” as Evans puts it.
Without going into the deepest spheres of DDD I suggest anyone who is keen to actually code something before going through all the literature, to start off with understanding those terms, which are the most important in my opinion: Domain, Model and Entity. These will quickly lead to your “Domain Model” which basically consists of entities.
At the start, your domain language (or ubiquitous language), should resemble a set of entities along with a naming and descriptions that everyone from business people to technicians understands and agrees with. Avoid technical terminology. Try to be meaningful when setting up your entities. Do not underestimate the distinctiveness of your domain language. The closer you are to reality the greater the use will be that your domain model will be able to provide.
Ubiquitous Language, Doubly Linked Lists and Magic Methods
Finally I am reaching the “Implementing” part. Imagine your domain as a knowledge base rather than a data base. For my DDD framework I designed a few base classes: domain, module, entity, attribute. And all my base classes are organized within my DomainManager. My domain objects are linked by a “double chained list” or “doubly linked list”. Some default methods help for example to get all modules of a domain or all entities of a module. And when I want to use my domain objects, magic methods come into play.
Let’s look at a simple question that should be answered by a business application. Usually the question itself originates from a human need. Of course there should be some sort of storage, e.g. an RDBMS where the data for the answer is stored. As a software developer it is yours to align those two.
Human (an Accounting Manager):
„I need a detailed list of all items of the invoice with the number A2014223“
In the Database:
SELECT * FROM phpMoney__accounting.invoice_items WHERE invoice_id = (SELECT id from phpMoney__accounting.invoices WHERE number = ‘A2014223‘);
$list = DM::domains()->phpMoney()->accounting()->invoice_items()->where([…])->execute();
The Method Magic
For the above example I am using PHP’s magic methods __call(), __get() and __set(). I am currently preparing a functional example along with source code for you to fork. So my next blog post will be exactly about that: How to use magic methods, what you should be aware of when utilizing them and, apart from the conceptual and DDD related reasons, what technical considerations led to my approach.
The Idea of using DDD and utilizing PHP’s features like magic mehtods is to allow your developers to write code in “domain language”. Imagine an IDE fully aware of your domain model, thus doing code completion for you! Imagine you one of them changes the domain model on a feature branch, and other developers get alerts upon checkout, which parts of their code need refactoring!