Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build, protect and deploy apps across any platform and mobile device
Automate decision processes with a no-code business rules engine
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
My discussion with Tony Baer at onStrategies the other day, along with Joe McKendrick's discussion with Ron Schmelzer, where Ron said (to paraphrase) "It's always a great time to invest in architecture," got me thinking; and that's always a dangerous thing.
There are a lot of people preaching the line "SOA is an architecture (not a solution or end state)." And, yes, I agree SOA is not a solution or an end-state.
But, I've got to wonder whether the "SOA is an architecture" mantra is just a cop out? Is it just a simple way to say "expect no measurable return in any time frame you'll care about so stop bugging me about it"? The benefits of architecture are fundamentally unmeasurable unless you can do a direct A-B comparison... which you can't. And, one thing I've learned is that if you can't figure out how to objectively measure something, you probably shouldn't be investing a lot in it.
The problem with focusing on "SOA is an architecture" is that architecture is perceived as needing to be complete before you begin building. First, getting an architecture "right" takes a lot of time (probably time that an organization doesn't really have). Second, things change - so what was "right" this year is probably not "right" then the next year.
There's clearly also a fallacy in saying "once we get the right architecture locked in, we'll be agile." Why is this wrong? Because if your architecture itself isn't agile (i.e. quickly changeable and adaptable to unforeseen circumstances), then fundamentally nothing you build on it can be agile in the long run either. If this doesn't make sense, I've blogged on a closely related topic in the past that might shed some light on the subject.
If enterprise architecture is your thing, that's good. I like architecture. Some of my best friends are enterprise architects. But, instead of focusing on SOA infrastructure as key to your architectural success, maybe you should be thinking "How do I build an architecture that itself is agile?" Maybe you should be thinking, "How do I build an architecture that will make it easy for me to adapt the next wave of architecture (whether it's EDA, RESTy, or unknown)?"
Now, on the other hand, if you're building applications to solve problems for your business, you should be thinking about how you harness the tools and techniques that are available to you to get your job done faster and better for the business stakeholders - regardless of what worked best on the last project. "Horses for courses" as my Irish friends would say.
These two recommendations (one to enterprise architects and one to the project) may sound disjointed, but they come together: An architecture that itself is agile can easily fit with projects based on different architectural foundations. Agility at both the project and enterprise level. Nothing better!
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.