Join the DZone community and get the full member experience.
Join For FreeAmazing thing this week! Imagine this case: developers need to access production application servers logs. These are inaccessible for now because application servers machines are production level. So they are placed in a different network zone. Between the AS zone and the DEV zone, there’s a firewall configured to disallow access from developers machines. In order to solve this, a meeting is scheduled and soon, the room is filled by system engineers and software architects, all buzzing ideas.
The most pragmatic idea, update firewall rules so that developers can access application servers machines is killed outright: security is security and our security team will never let us put holes in the firewall.
At the end, two solutions are still around:
- develop a web application that will display logs and which will be deployed on every AS
- configure the AS so they can serve the logs filesystem as a static webapp
What amazes me to no end is that the first idea was backed by the system engineers while the second by the software architects (including myself). I know full well the cons of developing a custom proprietary web applications: development costs (of course), maintenance costs, organization costs (who will be the product owner, who will asks for features, …) and so on. But it seems that our esteemed colleagues don’t know: they know nothing about our craft.
Now, since they are reluctant to “just update configuration”, and they not being less smart than us, they also mus have very really valid reasons to propose a custom development: these reasons we are blissfully ignorant because we, architects, in turn don’t know about their work.
We haven’t resolved the issue yet, and I think it will takes some time (read: some management decision). But this little story makes me think more and more about team organization: is it right to have architects on one side, and systems on the other (not counting developers, security, QA, etc. all neatly separated)? This experience is just another argument in favor of small project-dedicated teams including each profile and responsible as a team.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}