Tag Archives: github

Using AD…what? ADR?

Posted on by
Reply

And the ADR for using ADRs is there in ComposeUI/adr-001-use-adrs.md at main · morganstanley/ComposeUI (github.com)

If you are watching the new repo, you might have spotted that the first few PRs are about adding a set of “ADR”s, Architecture Decision Records.

So you could ask, why? You could ask the same question, why a project is using X instead of Y – actually a new person joining a team definitely going to ask the question, why you using Entity Framework and not NHibernate? And believe me, most likely you would hand wave and say “for historic reasons” because you would absolutely not remember anymore. And that’s generally very unfortunate.

Documentation. Yes, I’m also a developer, and I also hate writing documentation. Who doesn’t hate that? Actually, I think, above a given age, when you are being told ‘documentation’ you do have a particular picture in your mind, which is books and books of lot of pages, probably bound together using twines called project documentation while still using Rational Unified Process or Microsoft Solution Framework like I did? Or the other way around, yes, there are tons of documentation, scattered among different systems, hosted off the code, in wiki or something – gets outdated the day you write it, not part of the source control, not structured (or rarely), therefore, why to write it at all, again?

So, documentation, why hate it, but can it be done better? I don’t think I ever started to like writing documentation, believe me. But writing Architecture Decision Records, following a certain scheme in them and keeping them in the same git as my code – that’s more of my liking, believe me. So, just to summarize, an Architectural decision is a software choice. One that addresses either a functional or a non-functional (like project structure – or the fact you do write ADRs!) requirement that is architecturally significant – framework choices, programming languages you choose, OSes you target, data storage, communication patterns, persistence, validation, logging, telemetry; you just name it. Of course, you should not take the term “architecture” too seriously or interpret it too strongly. I mean, look at not-that-recent update of ThoughtWorks’s radar when talks about ADRs: Lightweight Architecture Decision Records | Technology Radar | ThoughtWorks – they went from ‘trial’ in 2016 and speaking about evolutionary architecture to a mainstream adopt in just a few years. And they also suggest to store them in version control instead of wiki/website. Let me finish it with the sentence from the Radar: “For most projects, we see no reason why you wouldn’t want to use this technique.” So, our http://github.com/MorganStanley/ComposeUI is not different 🙂

Going opensource – why?

Posted on by
1

Small update on Ok, so, where is the project? added as a separate post 🙂

I suppose you haven’t spotted yet – we just created a new opensource project, GitHub – morganstanley/Compose . It might worth explaining the why behind that choice.

It is always appropriate to challenge the need for a project to be open source, given the lack of foreknowledge of anyone else having a desire to use a platform versus the other possible options or their own proprietary one. While we have the desire and the capability to support this if it comes to be, it’s not the primary motivation. With a foundational architectural aspiration of a pluggable platform, it’s important for it to be possible to selectively choose components from open source and if needed, from commercial vendors that make sense given your requirements. There is no reason for a company to own every line of code or to find something available that tries to meet all our needs. Vendors will always yearn to get their foot in the door and being open source accelerates and simplifies partnerships through increased visibility and collaboration without the red/yellow tape or proprietary integrations or NDAs. We have already seen this model work successfully with other projects like desktopJS as ongoing collaborative efforts with vendors to use and extend simply for their own (sales) demos to others. While it is naïve to think they aren’t also doing this to make it easier for us to choose their platform. It has proven the usefulness of open source being successful in other ways than just marketing, recruiting or reuse by others. It is also a tool to better work with the industry to outsource or “buy” features off the shelf that give a commercial momentum with faster delivery. Having this project in the open is also useful to drive the roadmap of some companies by adding use cases that finserv developers need and expect.

Open source also provides us with innovative methods to explore different avenues of staff augmentation – e.g. working in an open manner eliminates the onboarding needs as well as associated overhead resulting in immediate participation and contribution.

A tangential benefit of being open source is keeping us free of binding ourselves unnecessarily to internal tooling and processes and implementation. By using off the shelf build infrastructure and GitHub capabilities we will be able to swiftly adopt and leverage industry leading DevOps tooling.

So what does open source mean to me? Whether you are operating on the cloud or on premises, you want to spend most of your time on solving the business problems in front of you, not on re-inventing the wheel of algorithms, APIs, pipelines, deployment and so on. Fortunately, we get to stand on the shoulders of giants by relying on robust well-maintained open source libraries or specialized vendor software, when appropriate. Most of the popular modern solutions work equally well on the cloud and in an internal infrastructure. In our view, .NET developers should be working on problems that are critical to the functioning of the company, and it’s the job of projects like this one to enable that focus by providing the functional foundational building blocks. We do help finding and creating the robust solutions to the generic problems so practitioners can remain focused on the aspects that are specific to their business. By developing battle tested code, harnessing the brain power within the OSS community and building relationship with selected vendors, we are able to provide the best-in-class tools and libraries for all .NET Developers. This amounts to less custom code scattered across, that becomes a technical debt, and results in an easier learning curve for anyone joining a firm – like ours.

Where customizations are required of other OSS projects, we promote contributing those changes back to the project on the firm’s behalf – this is in line with the overall firmwide OSS strategy.

We are doing .NET Core – .NET Core itself is a fairly young technology and the usage of it is also at the very beginning of its journey. Our mission, our approach and our thinking will evolve as .NET Core adoption matures and as the subject itself evolves. This will always be a collaborative effort and we do invite input from all of our constituents. This input allows us to be better informed and to better understand the needs of practitioners around the world. My group, my team will strive to be a resource for .NET Core expertise on desktop, cloud, software, vendor needs, advanced techniques, academic research and related topics. But for this, we need to go open source 🙂