Saturday, June 6, 2015

Communicating Enterprise Architecture

A main success factor for us is that we realized that business needs a vision not technical design. All parts of your organization needs to participate in the enterprise transformation. Only a small fraction has technical insight, the majority have other concerns. Therefore we have a “city” regulation plan for our systems landscape. Just like city planning. Politicians look at concepts and overall quality of a regulation, with blocks, roads, and parks (e.g.). They do not bother with the technical building drawings. This is where we think many EA projects fail; they tend to focus on the technical drawings, not the quality of life for the organization (eg. Population for a city).

The IT-regulation plan is a “City plan” and is a contemporary view of all major functional areas (systems) and their main functions. It has a color legend so that is proves to be a good transition architecture illustration. It is maintained 2 times a year to reflect ongoing projects and decisions from the portfolio board. Further more we have a roadmap for all existing systems (silos) and a modernization scenario which is the overall plan for major effort during the next 10 years. These are all used when describing the mandate of new projects, where the work effort is illustrated on the target architecture and the regulation plan.

The regulation plan has proven to be very good for communication our business for all parts of the organization. Even the Finance Minister has a A0 copy in her office. The power of is comes to life when business processes are explained as a “tour of the city”. People like stories and understand the effects on the city; where maintenance must be conducted or new building has to be erected. It really brings business and IT to the same table.

So take a look at our "City Plan". Although in Norwegian you get the idea of how a visualization of structure can form the basis of something to communicate upon.  The illustration is quite large so it is presented at

Creative Commons License
Communicating Enterprise Architecture by Tormod Varhaugvik is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Saturday, March 7, 2015

Proven architectural properties

We are now in production with our new scheme as of 2015; Ongoing reporting of wages live from all payroll systems around the country. My blogg has been about design ideas of 2010 and the demanding process of transforming our systems, knowledge and organization from silos to robust scalable 24/7.
We have managed a fundamental modernization based on a paradigm shift in software design and implementation

We have had a smooth start with great results:
  • Of 223.842 deliveries 97% get response of <15 seconds (end-2-end)
  • 24/7, peaking at 3.190 deliveries / hour with constant response (a delivery is all payroll from all employers)
  • "Micro services" architecture inspired by "Reactive Manifesto»
  • Changes and fixes rolled out continuously in the daytime, in practice 2-3 times per week
  • All business logic running live, also with consistency against previously reported data
  • Mainly Open Source
  • Our motto: "Simple, testable, scalable" (as described in previous bloggs)
  • Java version: 1.7 (soon Java 8)
  • XML: Built in JDK
  • REST: Jersey, Apache Http Client, Atom Feeds
  • Clients: HTML5, CSS3, Backbone.js, Angular.js
  • Servlet container: Jetty, Grizzly
  • Parallel handling: Akka
  • Engine: ElasticSearch
  • Distributed Coordination: Zookeeper

Proven architectural properties
The design from 2010 has proven abilities. Wise choices in 2010, broad organizational anchoring and continuous IT architecture and technology management, as well as trial and error has made this possible.
  • Few consecutive errors   
    Proves the ability to change. The system is understandable and we have control of it.
  • Frequent deliveries
    Ability to change. Quickly correct errors and introduce new functionality.
  • The performance was very much improved in a short time
    Scalability. "Design for the cloud"
  • The systems moved (unchanged) of the convergent platform within a few hours
    Lifespan principle. Open standards provide portability and market access
  • Solution in operation after 17 months
    Reuse. Cost effective and risk mitigation
The enterprise architecture process
"To put an idea out in life is a struggle for life. You must have steadfast faith in what you are doing"(Klouman)
  • Dare to be politically incorrect
  • Convince even the lagers
  • Even harder; make sure they understand
  • Anchorage target architecture at the topmost level, but every week you have to fight again with rounds of discussions (others or your lack of understanding, or political opposition)
  • Credibility; You must combine "listen and learn" with "motivation", otherwise you will be ignored or "eaten alive"
  • Dream Situation: Make sure that the purpose of a design is understood, so anyone believing in it will make it their own and improve beyond you own capability

Fun and scary statement on the way:
  • "We solve this with SOA, WebServices, ESB and BPEL»
  • "Employers are customers, purchase CRM system»
  • "XML has been tried out in Denmark, and it does not work"

Tax Norway is a large governmental organization of 6.500 employees, this type of transformation is demanding. Thank you everybody.

Creative Commons License
Proven architectural properties by Tormod Varhaugvik is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.