alphaspirit - Fotolia
4 development tools that bridge the architect-developer gap
There can be a frustrating divide between the role of software developer and architect in any organization. There are ways to bridge that chasm, and one of these four tools just might help.
There are plenty of tools and techniques that address the architect-developer gap, but not every tool suits every purpose. Some are better at strengthening the team as a whole, while others focus on the individual and enhancing skill sets. It's important to align your collaboration tooling with the needs of your team.
Here's a breakdown of four development collaboration tools and platforms that address the architect-developer gap. We include the pros, cons and scenarios where they are best suited.
GitHub is a collaboration platform that has tools to create a project base, code repository, documentation repository and team-building facility. It is also popular and therefore familiar to many developers. There is a myriad of add-ons that provide almost anything a project manager might want.
But, because there are so many different things you can do with GitHub, it's easy to get lost in the shuffle. GitHub is so open and communal that it won't provide a detailed and specific project discipline. But if you have a development environment that runs as a social community rather than a linear architect-developer flow, you can certainly use the collaborative aspects of GitHub to your advantage.
Sometimes, the best way to bridge roles is to find a common development tool. NetBeans and Eclipse are two closely related tools that can do the trick. NetBeans started as a Java integrated development environment (IDE) and evolved to handle most languages. Eclipse is a broader-based IDE with a host of plugins that accommodate different languages. Used correctly, either of these IDEs can unify a project.
Unlike the team-focused GitHub, NetBeans and Eclipse target the individual. If you need to train and support development teams, it's great to have a single tool that can do almost anything associated with program design, including the Unified Modeling Language (UML) and XML. With these IDEs, however, you still need to implement your own team process and development workflow. If you can do that, consider using either NetBeans or Eclipse as your bridge.
Is UML still relevant today?
UML traditionally served as the bridge between software architects and software development teams. In traditional development, architects defined software at a high level using UML. Developers would then take the models and convert them into code. There are plenty of UML tools and editors available, and many of today's development tools feature UML plugins.
But while UML still works today, it no longer holds a top spot in this space since it's harder to learn and doesn't readily lend itself to continuous integration or continuous development. UML's problems also tend to be exacerbated when you take it below the top level of application design. However, if your developers only work with top-level models, you can still use UML successfully.
Rational Software Architect
Many development teams understand that the best way to bridge the architect-developer gap is to use architect or modeling tools that integrate with development tools. IBM's Rational Software Architect is a great example of this type of tool.
Rational Software Architect offers a start-to-finish project environment in tool form. It enables flexibility in the team model and also imposes a structure on projects. These project structures can be as linear as a UML-driven team or as flexible as a social-driven CI/CD environment. However, Rational Software Architect implementation does not always integrate with other development tooling, which means you may need to scrap your existing tool set. If you're not prepared to do that, move on.
If your organization struggles to coordinate software elements with the projects around them, consider Holagent's RDD-100. In some ways, it combines the best of the venerable UML with the best of team management tools.
RDD stands for requirements-driven development, a paradigm designed to facilitate a structured team approach. RDD defines individual roles and activities in association with development requirements. RDD-100 models and links requirements and processes for both architect and developer roles -- a rare feature in a development tool. In terms of scope and impact, RDD-100 places at the top of bridging options, especially if you're prepared to take the time to adopt the tool and teach your development team how it should be used.