We have seen that companies have based their IT infrastructure around two platform types:
• Proprietary middleware stack (IBM, BEA, Microsoft, Oracle etc)
• Open-source software (often Linux, Apache, MySQL and Perl/Python/PHP; referred to as the LAMP).
We have had very negative experience with JAVA EE-application servers, like IBM WAS (WebSphere Application Server) and its ESB implementation (Enterprise Service Bus). JEE has traditionally been a path to vendor lock-in even though specifications are free and open. We feel this has led us to the recommendation to avoid application server dependencies. This, in turn, has led us to a server solution based on the open-source servlet containers Jetty and Tomcat. The idea behind ESB did not fit our demands properly and instead we based our architecture on a simple single database message poll solution, and various other integration techniques.
It has proven difficult to find an open-source project with a level of customization and functionality to match the requirements for this architecture. Therefore Nets has developed an Java library (core-proxy), and will in the future provide this as a contribution to the open-source community as free software.
My blog is basically about Architecture frameworks and Open Source. Architecture framework which defines how to organize the structure and views associated with an enterprise architecture. Client/Server solutions based on Open Source. Open Source (In house developed Source Code, external Open Source code). Development toolbox based on Open Source (Build tool, Version control, Test tools). Keywords her are Architecture framework and Open Source
Tuesday, March 22, 2011
Which application server (java) should you use…?
Open-source code is not only for idealists!
Today we find the environment for open-source code is not only for idealists. A company using open-source also has the possibility to buy support and help using the software better. We see today a lot of wealth creation in connection with services based on open-source. For the different companies using open-source we see better control, less errors and better services
.
.
Thursday, March 17, 2011
Which IDE (Integrated Development Environments) are you using?
Java developers in Nets today are using Integrated Development Environment (IDE) tools. The main two tools in use are Eclipse and IntelliJ IDEA. Eclipse is a free open-source tool and IDEA is not. Since we use Maven as the build tool, every developer is free to choose which IDE he uses, since Maven will ensure that we have no dependencies on proprietary to build, package or deploy our software. Eclipse is the most used IDE, but IDEA is popular in some departments. We estimate that 80% of the developers use Eclipse, and the rest is mostly using IDEA.
Monday, March 14, 2011
76% of our code is open-source code
Over a six month period we (Nets=old BBS) analyzed usage of open-source (code) by collecting data from 12-14 large development projects based on Java. Most of these projects have been initiated in connection with the Stay project. We have extracted the following vital statistical data from these projects
The source code deployed:
• In house developed source code (including libraries)
• External open-source code (including libraries)
• External closed source code (including libraries)
The result was amazing, data shows that approximately 76% of code is open-source code, less than 7 % is closed external code, and 17% is developed in-house. The external code is reduced day by day as we convert our old code from WAS (WebSphere Application Server, from IBM ) to Jetty.
The source code deployed:
• In house developed source code (including libraries)
• External open-source code (including libraries)
• External closed source code (including libraries)
The result was amazing, data shows that approximately 76% of code is open-source code, less than 7 % is closed external code, and 17% is developed in-house. The external code is reduced day by day as we convert our old code from WAS (WebSphere Application Server, from IBM ) to Jetty.
Wednesday, January 12, 2011
IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture.
Today both IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture. One makes this as prerequisite architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.). But is this smart when one expect that the business strategy will last much longer than the IT strategy?
Christian Wig has some interesting remarks:
“When people tell me that the IT strategy should be 'driven' by the business strategy, I normally tell them that their underlying paradigm is fundamentally wrong. Or I ask them to provide me with a business strategy having a 10 years’ time perspective, which - of course - never exists (and never should exist). Or, I tell them that if we meet again 10 years from now, in the same boardroom of the same company, that they will be highly frustrated by how the IT architecture of the 2020s actually prohibits business development - driven by the 'business-driven' IT decisions we made together back in 2010.
This paradox is a quite critical one facing most businesses today: The technology platform that supports their business areas, products and processes have a much longer life-span than the business strategies which the technology is supposed to support. And at the same time, no technological platform will be 'prepared' for handling anything that wasn't explicitly foreseen and planned for. So the ability to look around the corner, and actually plan for the unplanned, is what I really focus on.”
Christian Wig has some interesting remarks:
“When people tell me that the IT strategy should be 'driven' by the business strategy, I normally tell them that their underlying paradigm is fundamentally wrong. Or I ask them to provide me with a business strategy having a 10 years’ time perspective, which - of course - never exists (and never should exist). Or, I tell them that if we meet again 10 years from now, in the same boardroom of the same company, that they will be highly frustrated by how the IT architecture of the 2020s actually prohibits business development - driven by the 'business-driven' IT decisions we made together back in 2010.
This paradox is a quite critical one facing most businesses today: The technology platform that supports their business areas, products and processes have a much longer life-span than the business strategies which the technology is supposed to support. And at the same time, no technological platform will be 'prepared' for handling anything that wasn't explicitly foreseen and planned for. So the ability to look around the corner, and actually plan for the unplanned, is what I really focus on.”
Monday, January 3, 2011
Is it possible to manage the enterprise architecture without implementing architecture principles?
From the Open Group (http://www.opengroup.org/architecture/togaf8-doc/arch/) we find the following definition of different principles. Depending on the organization, principles may be established at any or all of three levels:
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations, but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization. In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).
Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.
Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can be further divided into:
o Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
o Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations, but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization. In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).
Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.
Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can be further divided into:
o Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
o Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems
These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.
Is Maven still the best build tool?
We use Maven as build tool; it handles and centralizes all build, dependencies, reporting and documentation. Since we do not rely on restricted software and do not deploy our applications into a javaEE environment we can package our software with all dependencies included. Maven is configured to build a zip archive of our servers with all configuration included ready for installation on any server using simple Unix and Linux commands. Maven does not lay any restrictions on which IDE the developers use.
Subscribe to:
Posts (Atom)
Blog Archive
Open Source code
- http://jakarta.apache.org: The Jakarta Project offers a diverse set of open source Java solutions and is a part of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.
- http://www.sourceforge.com: Open Source market place which is not only limited to Java source code. Also a meeting place for people and companies who want open source develop. This is place for both developer and people/companies that founds the different projects.
- http://www.collab.net/: Open Source marked place which is not only limited to Java source code
- http://www.gjt.org/: Called Giant Java Tree and is limited to code that follows the GNU Public License.
- http://www.gamelan.com/: This site Gamelan is well known and has been around for a while. This site has been commercialized and is now part of http://www.developer.com



