Skip to main content

Architecture at CraftConf



At Craft Conf, there were some presentations about software architecture. I visited all of them and also searched for this subject in other talks. It was interesting to hear the same concepts from more places and to put together a picture how software architecture looks like in the mind of the presenters of today’s conferences.

Stefan Tilkov: Architecture War Stories. It was indeed about weird stories from real life. I wrote down two things: If something is sophisticated, probable you shouldn’t do it. And having many architects is wrong. Many people liked this talk very much but I’m not really interested in real stories. I’m rather interested in the causes behind the stories to be able to avoid situations which head to weird architecture. Luckily for me, other talks were more abstract.

The title of Rachel Laycock’s talk contained the very fashionable word combination “Continuous Delivery” beside “Architecture” so I anticipated it will be great, and it was. Rachel came with the same mindset what I heard two years ago at Devoxx from Kirk Knoernschild. She used the phrase: Architecture is the stuff which hard to change. Architecture isn’t how the big parts fit together as some older sources say. She listed the five most important principles:
  • Last responsible moment. - defer decisions if possible. (Managers demand a stake in the ground approach because it’s more comfortable for them but it’s in violation with modern architecture principles like ‘last responsible moment, defer decisions’.) 
  • Architect for evolvability - don’t try to fix everything. 
  • Postel’s Law, a.k.a the robustness principle: - Be conservative in what you do, be liberal in what you accept from others. In other words, code that sends commands or data to other machines (or to other programs on the same machine) should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear. 
  • Architect for testability - (good design is testable) 
  • Conway’s Law. - The Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. Another thought about Conway’s law from Fred Brooks (mythical man-month): “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organisation is important to effective design.” 
She mentioned microservice architecture as a good direction (not the only one who mentioned it) and explicitly suggested not to use ESB or at least not to put any business logic in it. There were three recommended readings (all from Martin Fowler): The Strangler Pattern, Branch by Abstraction - these are articles and a book: Continuous Delivery. Well, not too many words were spoken about Continuous Delivery.

I’ve heard an important aspects about Continuous Delivery at other talk: Don’t use branching but use flexible runtime feature flags.

Title of Simon Brown’s talk operated with the other fashionable word “Agile”. I didn’t like this talk as much as Rachel’s one, maybe because I didn’t hear what I wanted. Simon said, that one architect should be enough in a company, or at least very few. It was said by Stefan Tilkov also, but in other articles I saw opinions about being all developers some kind of architect is the good way. I think the truth might be somewhere between. The other thing which I didn’t like the need for a proper UML diagram of the system, although, sometimes I also print a diagram for myself of the currently developed software, but it’s not necessarily standard UML and far not proper. It’s not maintained together with the code. He mentioned C4 which is also in connection with diagrams. In his definition: Architecture is the significant structure elements or architecture is the structure down until component level. Further advices were: Just enough upfront design is enough, never do Big Upfront Design. He recommended this book. I liked he mentioned that there’s something between monolithic and the very fashionable microservice architecture, it’s impossible to make it in one go, it can be implemented by a continuous transition.

In Nat and Steve’s presentation’s title there were no Architecture just SOLID. I liked very much the different kinds of pasta they showed for us, especially because we were before lunch. So, basically there is the spaghetti code which we know all, it’s the good old procedural legacy code. But OO code is all nice and clean? Well, maybe not. There is lasagne code, which is OO but it’s just layers on top of each other and you never get to the bottom. Ravioli code is also OO but you can’t get how and why the different objects and classes piled up on each other, possibly by the dependency injection framework. And there is OO spaghetti code which is made by events and event handlers and it’s similarly hard to unravel it’s behaviour like the procedural code (if not harder).

Michael Feather’s talk’s title was very specific because it contained the “Conway's Law”. He recommended to read the Leaky Abstractions from Joel. Mentioned Feature vs. Component teams. In some corporation teams may work on features or components and it’s reflected in the software itself. Further terms or recommended practices were: oscillating teams, production coverage, silent alarms, ownership.

Other very popular subjects of the conference was Continuous Delivery and Functional Programming which both have some connection with architecture. Though reactive programming and functional idioms very low-level stuff, not how the big parts fit together and not component-level design, they play an important part in architecture. So yes, I could cite some other talks where architecture was concerned but it’s time to stop here. I learnt a lot, everybody should learn a lot about it, and it’s not the last post from me about this subject.

And don’t forget, that quality means many different things, but customers are interested in functionality.

Comments

Popular posts from this blog

Client's transaction aborted

I've met the above error message using a Wicket 1.2 / EJB3 intranet application under Glassfish v2 . Here is the more particular head of the stack trace: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:3394) at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3274) at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1244) at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195) at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127) This exception raised on the integration server sometimes, randomly, for simple page fetch operations. After pressing reload on the browser, the operation was usually successful. I couldn't reproduce the failure on the local machine where I regularly restart the app server and

jxl.log

In an intranet production environment we have running a Glassfish v2 appserver with several J2EE applications which all use JexcelApi , a.k.a JXL, which is an open source library for accessing, generating or manipulating Microsoft Excel documents. We use version 2.6.3 of JXL because it's the recent one in the Maven repository which we use, however, at the official JXL site there are newer versions. Additionally we have log4j and Java Commons Logging (JCL), ignoring Glassfish's JSR-47 Java Util Logging (JUL) facility. Application #1 uses purely log4j and gets its log4j.xml config from a custom location. Application #2 runs Java Commons Logging with no explicite configuration file given, so JCL uses the default JUL facility of the appserver. Application #1 had been running for a long time without problems but when we installed #2 we realized that a jxl.log file had been created in the glassfish/domain/domain1/config directory and it's rapidly growing. As it happens, we

Brillien

There were three presentation as usual at the 14th Java User Meeting at Budapest yesterday, but this time I'll write only about the first one. Imre Fazekas had been invited from Debrecen to make a presentation about Brillien , their Java enterprise platform. It's an alternative way of modeling and implementing business logic in place of Java Enterprise (J2EE) Technology. It uses invasive programming model which means we have to extend classes from Brillien superclasses and we may use annotations. The whole system based on asynchronous XMPP communication and a set-context-flow concept. It's something like an application server, but uses a more logical and set-based approach. As the presenter said, it has very good speed and performance characteristics. Currently there are no IDE or other tools for editing models because this is a very young project, however a Maven plugin and a Maven archetype is accessible on the homepage. A very good introduction and tutorial can be also