3. Once upon a time,
a softwareproject
began…
“The client has a budget and wants the software fast.”
“Quality is expensive, there’s not enough budget for it.”
“Let’s just get this functionality working.”
“The client needs to software urgently, we can’t wait.”
“Let’s higher the juniors, we’ve got limited budget and need many
pairs of hands.”
“Clean code? Who cares about code? That’s just in books, it doesn’t
really work in the real world…”
“We don’t want to waste time on automated testing, let’s just do
development.”
“This is just a simple CRUD application, it’s really easy to implement
and it shouldn’t take much time.”
“As long as it looks good, that’s all that matters – after all, no one
sees what’s in the background.”
“Risk management? That’s just for the pessimists, this is a really
simple project, what could possibly go wrong?”
4. And then,a few
months into the
project…
“There’s too many bugs, let’s just hope it works for the demo”
“We’re running out of time! Solve this bug and deploy the hotfix!”
“We’re behind schedule, so we need to speed up.”
“Why is it taking so long? These are really simple functionalities, why
is it taking so long to implement simple changes?”
“There’s a really important meeting coming up – with the big bosses
– and if we don’t fix these bugs, it will be really embarrassing”
“Why aren’t the developers working fast enough? We’ve got so many
pairs of hands, why is the progress so slow?”
“Our key developer has left – he knows all the nitty gritty details, how
will the team cope?”
“Take a deep breath, remember stress management and keeping
calm under pressure – I’m sure we’ll somehow solve this, just like the
projects in the past”
5. And finally, the
projectending…
“It’s finished, over budget, really late, and with so many open bugs”
“Let’s do the routine lessons learnt meeting – but there isn’t really
nothing to learn, we’ve known all along that you can’t have both
quality and speed”
“At least this project has finished, but surely the next one will be
better”
“… But then again, everyone knows this is the reality of software
development projects, it’s the way it’s always been and there’s
nothing we can do about it”
“Quality and speed – as the golden saying goes – we can’t have both”
7. Welcome to the Optivem Framework
Optivem
Framework
accelerates your
enterprise
software
development
Open Source
Framework
Rapid
Development
High Quality
Software
8. Optivem Framework Motivation
Optivem Framework was motivated by the pains faced in the software development
industry, esp. the quality vs speed trade-off
Traditionally, developing high quality software required much higher up-front effort,
in terms of designing architecture, setting up code standards, writing re-usable code,
adhering to best practices etc.
This was often in conflict with time / budget / resource limitations – and in those
situations, these “pragmatic” factors had higher priority, leading to compromises in
software quality
9. Optivem Framework Motivation
To solve the challenges faced in software development (quality vs speed tradeoff), the
Optivem Framework was designed to provide you with a high quality out-of-the-box
architecture, ready made for needs of enterprise software, helping you build software
with quality right from the start
But at the same time, Optivem Framework is designed to increase developer team
productivity and reduce the total development time, reducing both the time for
architecture as well as ongoing development, providing default and base
implementations to reduce amount of boilerplate code, yet at the same time
providing extensibility for custom implementations
To summarize, Optivem Framework empowers you to build high quality software fast
12. Optivem Framework Architecture II
Clean architecture. Out-of-
the-box system.
Enterprise modelling.
Supporting customer
requirements.
Automated testing. In-built
quality processes.
• Clean Architecture
• Hexagonal Architecture
• Onion Architecture
• Domain Driven Design (DDD)
• Use Case Driven Design
• Test Driven Development (TDD)
• Acceptance Test Driven
Development (ATDD)
13. Optivem Framework Architecture III
Core
Domain - Enterprise
domain model and
business logic (DDD)
Application -
Enterprise use cases
and workflows
Infrastructure
Integration with
databases and
external systems
Implementation
using common third-
party frameworks &
libraries
Web
Exposes Application
Layer as REST API
services
Exposes Application
Layer as Web MVC
Application
Test
Unit Testing (TDD)
Integration & System
Testing (ATDD)
16. Optivem Framework Standardization II
Standardized
Development
Standardized
architectural layers
Standard interfaces
and base classes
Code Quality
Standards
High quality clean
Code standards
Follows software
development best
practices
Less Code, Faster
Reduce amount of
boilerplate code
Develop software
applications faster
19. Optivem Framework Extensibility II
Plug & play
extensibility
Every component is
replaceable and
extensible
You have flexibility and
freedom both now and in
the future
Default
implementation
Provides you with default
implementation using
common libraries
Use these default
components for 80%* of
your common needs
Custom
implementation
Allows you to implement
fully custom components
Useful in those 20%* of
situations when you have
really custom needs
* An approximation using the Pareto principle