...
Can share about
(01-agenda-2.jpg)
What people tell me about why they don't use Apache Isis
Our Asciidoc based stuff
Anything to do with framework internals
...
New UI stuff upcoming in v1.15
Erik's app
Jorg's app
What people tell me about why they don't use Apache Isis
Incode Platform
- reorg add-ons
...
- Docker + containers
- gitlab
...
Discussion: "How evolve framework going forward"
...
Do we wrap automatically in v2.0?
- yes!
Discussion: Value Proposition/
...
Marketing
(03-valueproposition-1.jpg and 03-valueproposition-2.jpg)
JEE vs Spring
Apache Isis' Value Proposition / Marketing
(provided by Patrick Pliessnig)
Part 1: Apache Isis market boundaries
...
Now comes the more difficult facets:
I think at this level we have two types of properties. The first type is more interesting to IT-Management and the second is more interesting to the core business of a company. It is important to note however that both types of properties have business value, but their respective value is for different parts of a company.
...
This framework is such a versatile and powerful tool that it is hard to deal with it on a marketing level.
Does it fit mainly into one category ( market )? Or does it create a new market altogether and is unique in this market?
Need to find out! Anyway, the Apache Isis applications I am aware so far point me to the direction of the core business level of a company:
- The application of the social welfare department of the Irish governement is managing benefits for the people.
I guess this application manages the core business of this department. - Estatio manages some important aspects of the relationship between ECP, their real estate properties and their clients. Seems to be part of their core business ( service ).
But part of it is probably also where ERPs are used ( resource planning ) - Looking to what I want: Apache Isis helps me to generate business proposals to prospective clients. Seems to be part of my core business too.
( my business problem Apache Isis helped to solve so far, is to shape the concepts of my future products ) - Jörg: helps himself to manage his own job. His own job is his core business.
- ( I didn't get really how Eric's application integrates into his company's overall business )
Of course there are also fields where Apache Isis do not fit easily ( depending on the context ). The autogenerated UI for example is a horror for marketing-departments in companies if they seek to attract clients on their customer plattform. They need self styled UIs to make a difference for their clients in a competing environment. So obviously - in this case - Apache Isis will not help out of the box. They need specific viewers.
...
As far as I can see it, Apache Isis has a bias towards business management systems in the core business domain of a company.
It can therefore be beneficial for Apache Isis to market its properties in a way that makes sense to the people in this domain.
Part 2: Where does Apache Isis want to go?
...
(nb: Patrick has done a lot of further thinking on this subsequently; see lower down the page)
"Is Apache Isis for you?"
- fail-fast/disqualify
- is IT a cost centre, or a profit centre
- do you own your IT?
- The minimum information for your business
- Seasoned developers
- do your IT guys like jazz? (!)
Who are our customers?
- those who want to change
- those who have a vision
- those who (should have recognised that they) need a feedback loop
Why do we get veto'ed (by technical guys)?
- JDO (not Hibernate/JPA)
- Wicket (not Angular)
Do we care though?
- NO! (Dan: though in discussion, I think we decided that we did)
- Need to create excitement, not reasoning
Marketing/website
- landing page should be for CTOs/IT managers
- "metrics to impress", eg EUR bns annually paid by NO system in Ireland
- Stuff for University departments
- Enlist marketeers
What is our USP?
- rapid development
- evolves with your organisation
- "flows with you"
- just focus on the domain
- which will change
- digitize your knowledge
Killer apps
- Domain as a service
- in the cloud
- drop "naked" JAR file into Isis, have it "light up"
- a little like Ionic Creator
Use cases for "Meta-model in a box" (embed Isis within Spring say, Dan: as per chapter in my NO/DDD book)
- generated reports
- Javadoc
- PlantUML/graphviz visualizations
- selling (XML representation)
JEE vs Spring
(04-jee-vs-spring.jpg)
We voted to stay with JEE, not take an unnecessary dependency on Spring
(Dan: I recall it was said that being able to boot from within Spring Boot would be worthwhile to provide, though)
Apache Isis' Value Proposition / Marketing
(provided by Patrick Pliessnig)
Part 1: Apache Isis market boundaries
As a follow-up on the marketing/renaming topic of IsisCon I had some thoughts, I would like to share with you. Maybe this could lead to a more in deep discussion on how to broaden the use and the community of apache isis.
My observation was that the discussion focused implicitely on talking to other IT people. But with marketing we need to define more stuff like to whom we want to talk really, on what markets we like to focus and what are the appropriate properties of apache isis for the choosen market. while marketing is necessarily an opiniated discussion, Apache Isis needs to have a sharp vision to succeed in a market. Like in software development, the market structure follows patterns. I think it is useful to know these patterns and to structure the discussion accordingly.
During the conference the discussion was principally bottom-up and reflected the view of the community. In this mail I decided to take a top-down approach to give the market side more weight.
Obviously if Apache Isis wants to succeed in a market, it needs to have the right marketable properties that give added market value to that specific market. As a consequence we need to know both 1) the marketable properties of Apache Isis and 2) the properties of the specific market that fit.
In part 1, I want to lay out some thoughts about the market properties of Apache Isis while in part 2, I want to talk more about the market itself and its patterns. Part 3 is dedicated to some thoughts about how to hook up in the market.
Apache Isis market bounderies
For me Apache Isis has many facets that make it quite difficult to categorize it correctly and therefore to sell it.
Some facets are quite easy though:
- It is rooted in the Java world ( not C#, VB, PHP, etc ), datanucleus, jdo, bootstrap and other technical stuff
that one is really easy. It talks only to software developers and their worlds.
the market value is quite limited. Properties like mainstream or not mainstream, Microsoft or Open-Source, etc, come to mind. - It follows some technical patterns like Wickets ( some say it is MVC, others deny completely Wicket being MVC ), RestApi, etc
these aspects talk to software developers too and their cultures or ideologies.
the market value of these aspects is also limited. It mainly draws bounderies of whether a company has the right culture to deal with Apache Isis or not. - It follows some domain related patterns like model driven, domain driven, naked objects, DCI, mixins, etc
these aspects have arguably more market values as it is easier to make the link to the business world. Still, those patterns talk mainly to IT people.
If you want to make market value out of them you need to think thoroughly on how to sell them, but it is probably feasible.
Now comes the more difficult facets:
I think at this level we have two types of properties. The first type is more interesting to IT-Management and the second is more interesting to the core business of a company. It is important to note however that both types of properties have business value, but their respective value is for different parts of a company.
- Properties for IT-Management
Here come properties like Maintainability, Lifecycle-Management, Team-Management, Quality-Management, etc. It is interesting to note that with this type of properties we talk to the Head of IT-Management. Those people focus on operation and need conservatism. As the saying goes: never change a running horse. Also at this level, IT-Operation only costs. Period. One very important question is how to cut down costs. - Properties for the core business
Here come properties that support those parts in a company that actually generate the business value for the company (with their customers).
At this level I would see properties like Rapid Application Development, Closing The Feedback Loop. Autogeneration of UI, relationship with non-technical people, etc. Those people generally follow their markets. If they don't they will loose customers.
Anyway this is the only level where we don't talk to IT-People. They have different needs and expect different things from an IT-System. What we definitely need to understand here is that, if an application helps to improve the core business, those people won't see it as a cost position, buth rather as a benefit for their business value ( with visible return on investment )
Where does Apache Isis really fit:
This framework is such a versatile and powerful tool that it is hard to deal with it on a marketing level.
Does it fit mainly into one category ( market )? Or does it create a new market altogether and is unique in this market?
Need to find out! Anyway, the Apache Isis applications I am aware so far point me to the direction of the core business level of a company:
- The application of the social welfare department of the Irish governement is managing benefits for the people.
I guess this application manages the core business of this department. - Estatio manages some important aspects of the relationship between ECP, their real estate properties and their clients. Seems to be part of their core business ( service ).
But part of it is probably also where ERPs are used ( resource planning ) - Looking to what I want: Apache Isis helps me to generate business proposals to prospective clients. Seems to be part of my core business too.
( my business problem Apache Isis helped to solve so far, is to shape the concepts of my future products ) - Jörg: helps himself to manage his own job. His own job is his core business.
- ( I didn't get really how Eric's application integrates into his company's overall business )
Of course there are also fields where Apache Isis do not fit easily ( depending on the context ). The autogenerated UI for example is a horror for marketing-departments in companies if they seek to attract clients on their customer plattform. They need self styled UIs to make a difference for their clients in a competing environment. So obviously - in this case - Apache Isis will not help out of the box. They need specific viewers.
Conclusion so far:
As far as I can see it, Apache Isis has a bias towards business management systems in the core business domain of a company.
It can therefore be beneficial for Apache Isis to market its properties in a way that makes sense to the people in this domain.
Part 2: Where does Apache Isis want to go?
Looking from the other end, the question is what makes a market? The answer here is quite easy: you have consumers that consume products or services. Those consumers have expectations and the companies are here to produce those products and deliver those services and sell them.
The overall way from an idea or concept to a product or a service is a value chain [1] where each link of the chain adds some value.
Companies are all organised around this value chain. They are simply a link of this value chain. They also probably cut the value chain into smaller links within the company.
To organize a company you always follow the same general pattern:
- You have the core business which is the value chain of the company.
The company's value chain is strongly driven by external factors as the company needs to adapt to the market. In dynamic markets the value chain is dynamic too and vice versa. In Eric Evan's terms I would say that the company's value chain corresponds to the core domain with its domain vision ( the company's vision & mission in the business plan ). The modeling of this core domain needs particular attentation as it can destroy the business if not well done. - You have the management process (the leadership) of the company. I don't know too much about it, but tools like datawarehousing, business objects, Reporting-Tools in ERPs, etc belong to here. In some way, it represents the user/navigator of an organisation.
- You have the supporting processes: IT, Finance, Quality, Human Resource, etc.
Supporting processes are always(?) cross cutting concerns. You always need them, but they only cost a lot. Supporting processes tend to be conservative. Financial accounting for example is very conservative. IT-Management tends to be conservative too, as their main task is to keep the horse running within a given budget. You generally don't need to change a supporting process as long as it produces meaningful results for the value chain. If you want to change it, it is very often to cut down costs.
This is the traditional domain for ERPs [2]. They want to be a supporting process for your core business and are therefore organised with the company as the center of everything. For example a property like stability is more important than agility. For example the accounting module in a ERP is seldom a problem. - And last but not least you have the organisational units.
Their use is to master complexity. In Software terms they correspond to modules and/or bounded contexts.
An interesting aspect is the role of ERPs in a company. They started in the 80's/90's as tools to standardize and industrialize supporting processes in a company. They built on the success of industrialisation of goods. Stability and cutting down costs was important. But at the end their promise to integrate everything also included the value chain. In DDD's term I would say, they crossed their bounded context. Then the economy slowely moved from goods to services with much more dynamic value chain patterns. And at this point the ERPs pattern became more and more a problem because their low agility could not cope with the dynamics of services.
I remember in the 90's when I did some work in the Telecom markets which today is quite service oriented. The largest Telecom company in Switzerland had a new market strategy to comply with the new market conditions. Remarkably six months later they changed their market strategy to comply with new market conditions. They said so, not me. In my opinion they were just greedy and therefore shortsighted. But this pattern of changing market conditions repeats itself again and again, faster and faster for the moment.
Anyway, today we live in a quite service oriented economy. The value chain of a company has become much more dynamic than before. Change management is much more important than before to comply to new market conditions. And this is the situation where ERPs fail to deliver and Apache Isis ( as usual ) delivers.
Examples:
- Social welfare seems to be quite a dynamic thing in Irland (external factor: politics). The department's release policy of their naked-object system is accordingly. Feasible with an ERP?
- My project with Creabeton tells the same story. We proposed them with Colab another new level of service for their products ( thereby modifying their value chain ). For this we need to exchange information with their ERP. When the software developers of the ERP knew about Colab, they said: we can do that too. So why didn't they do it already?.
Conclusion so far:
One aspect of Apache Isis which seems to be quite unique is its ability to easily go along with an ever changing value chain. The more value chains are dynamic the more important is this ability. This is because Apache Isis overall pattern is naturally made for change and unlimited flexibility while the overall pattern of ERPs is made for stability. ERPs are naturally weak or not useful at all in a dynamic value chain.
Therefore my proposition is to think about this unique feature of Apache Isis as a unique selling proposition.
It could be described in terms of 'value chain engine', 'service support engine', 'play your own tune' ( your own business strategy ), 'shortcut' ( from idea to deployment of a new value ), 'change support tool', 'digitize ever changing knowledge', 'cool' ( place where the business happens ), etc, etc, etc.
With such terms we directly speak to the people dealing with the core business of the company ( not to the IT-people ). Also, if they can see Apache Isis as a tool to improve their value chain, cost is much less important. The ability to improve the income by staying close to the market with the best service in the world, is much more valuable.
[1] https://en.wikipedia.org/wiki/Value_chain
[2] https://en.wikipedia.org/wiki/Enterprise_resource_planning
Part 3: lowering the entry level for Apache Isis
Closely related to the question where Apache Isis wants to go is the problem of the entry level.
I completely agree with Oscar's argument that PoJo's without annotations would considerably lower the entry level.
I also think that meta annotations with sensible defaults could do the job together with the 'hello world' example.
Still, these propositions have the software developer ( in the it-department? ) in mind.
If we want to talk directly to the user that works within the value chain ( often called the power user ), we could go one step further.
A good lesson here ( in my opinion ) is given by the strategy of open source 'simple groupware'.
Simple Groupware is the php framework I used to create Colab applications. It has some properties in common with Apache Isis. It considers persistence and presentation a cross cutting concern and deals with it more or less automatically. A difference is that domain objects and their respective domain types are configured with xml-schemas that can also include JavaScripts. More complex extensions can be achieved by hooks into php code ( api ). the use of simple groupware is quite domain driven without it being explicit.
Simple Groupware offers a simple default groupware with a lot of default domain types ( modules in its vocabulary ). It is very easy to install that default groupware and execute it. A power user or a software developer can immediately use the application in a productive environment and when need arises start modifying the domain types ( hot loading of modifications included ) or add new ones.
The result of this strategy was that the framework attracted a lot of users that were not software developers. they started using the default application for their own business and learned how to modify an xml-schema. When it came to extend with php code they often started participating in forums or hired php programmers.
In the best times, the framework had thousands of downloads each month with a spike of 23'000 downloads in february 2011. also when googling for 'groupware', it came into the top 5 listed.
The problem was the maintainer, a difficult person working probably alone. He couldn't manage to enlarge the maintainer team and then he suddenly disappeared without reason and left simple groupware alone. Since then of course the downloads diminshed and nobody took over for maintenance.
Anyway the point is this:
It could help enlarge the community and the application base of Apache Isis, if there would be a default application to install and use.
Once a user is in, there is some likelihood that he joines the community. Also it is much more probable that an it-department will accept Apache Isis after a while because there will be established need for it within the company. And therefore much less likelihood for vetoing.
Having PoJo's without annotations could be of tremendous help for Non-IT-Power-Users. Only some knowledge of how to create simple Java objects would be needed. No datanucleus or similar technical stuff.
Of course default domain objects are somewhat against the spirit of domain driven design. Still, people are gregarious and they tend to follow each other ( and after a while they make their own way ;-) ). In that sense the functionality of a default application could be described as 'as simple as possible to be useful' and as 'extensible as possible'
I hope this makes sense....
-- Patrick
Kevin's Notes
from Kevin
(Written at the conference and first posted to the private mailing list [only because the notes were incomplete])
Dear all,
Some interesting topics are being identified at the Apache Isis "IsisCon 2017". In order to try ensure that no-one is left out, I will be listing the topics and ideas, to give you the opportunity to hear what is being talked about and offer your own input.
- How much "bleed through" annotations are acceptable?
The Apache Isis POJOs currently have many annotations that provide ?
- Cleaning up the Framework code
On the horizon is support for JPA with the associated dependence (via DataNucleus) on Java 8. This is an opportunity to remove obsolete/deprecated methods/annotations/etc and consolidate (bump the major version number, if we still intend to honour semantic versioning).
- What is Apache Isis's responsibility on a naked class?
The framework assumes defaults (according to a defined convention). With no additional annotations, how should the framework treat POJOs? It could, for example, assuming that all public classes are entities, and all public methods are actions. Any other desire would be communicated with additional annotations (is a service, mixin or non-entity).
- Prototype to Production
The "bare" vs "meta annotation" vs "full fat" (production) route. When starting a new application, the developer can start with naked, non-annotated classes. They can use this quickly put together the initial application. Eventually they will want to go to full production. Apache Isis (v2) would have value-adds (like add-ons) that switch on more and more checks that perform sanity checks that require additional meta-data (annotations or XML, etc).
- Wrap (v2)
All objects will be wrapped. There will still be an "unwrap" WrapperFactory method for when it is programmatically justifiable.
- Social welfare seems to be quite a dynamic thing in Irland (external factor: politics). The department's release policy of their naked-object system is accordingly. Feasible with an ERP?
- My project with Creabeton tells the same story. We proposed them with Colab another new level of service for their products ( thereby modifying their value chain ). For this we need to exchange information with their ERP. When the software developers of the ERP knew about Colab, they said: we can do that too. So why didn't they do it already?.
Conclusion so far:
One aspect of Apache Isis which seems to be quite unique is its ability to easily go along with an ever changing value chain. The more value chains are dynamic the more important is this ability. This is because Apache Isis overall pattern is naturally made for change and unlimited flexibility while the overall pattern of ERPs is made for stability. ERPs are naturally weak or not useful at all in a dynamic value chain.
Therefore my proposition is to think about this unique feature of Apache Isis as a unique selling proposition.
It could be described in terms of 'value chain engine', 'service support engine', 'play your own tune' ( your own business strategy ), 'shortcut' ( from idea to deployment of a new value ), 'change support tool', 'digitize ever changing knowledge', 'cool' ( place where the business happens ), etc, etc, etc.
With such terms we directly speak to the people dealing with the core business of the company ( not to the IT-people ). Also, if they can see Apache Isis as a tool to improve their value chain, cost is much less important. The ability to improve the income by staying close to the market with the best service in the world, is much more valuable.
...
Part 3: lowering the entry level for Apache Isis
...
I hope this makes sense....
-- Patrick
Kevin's Notes
(Kevin has posted some notes to private@ , I've asked him if he would be happy to move them here)
Jorg's "Framework Qualities"
...
Name Ideas
write-up by Dan Haywood
also documented at
| Jira | ||||||
|---|---|---|---|---|---|---|
|
At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant lieutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants lieutenants don't "veto" our framework for unimportant reasons... won't address here).
...
FWIW I've listed these in my (Dan's) own preference order
Attendees
(Should this list be private for any reason?)
- Dan Haywood
- Jeroen van der Wal
- Jörg Rade
- Kevin Meyer
- Patrick Pliessnig
- Óscar Bou
- Marc Alvares
- Hessel Bakker
- Rosco Kalis
- Johan Doornenbal
- Jonathan Doornenbal
- Erik de Hair
- Sebastian Slutzky
- Bilgin Ibryam
- Jan-Willem Meyling