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
As I was reading Dave Linthicum's flip-flopping denial, I kept asking myself how someone could both "resist the temptation to redirect resources toward tactical business needs" while at the same time "focus on short term objectives that are directly related to the generation of revenue"?
Dave clearly believes these statements are consistent with one another. So, to understand Dave's point of view I realized I had to delve a little bit deeper into the interplay between strategy and tactics.
First, it's important to recognize that tactics are the set of actions taken, and short term objectives met, to achieve (longer term) objectives set by strategy. That is, "tactical" actions unrelated to the strategy aren't tactical at all - they are just "doing stuff". I'll assume, though, that Dave really means tactical (not "doing stuff") when he says "tactical".
Here's the tricky part: your organization will have both a business strategy and a SOA infrastructure strategy.
If your business strategy and SOA strategy are out of alignment, then a tactic to achieve one of the strategies may negatively impact the other strategy. That is a tactic to achieve your SOA strategy may negatively impact your business strategy (and vice versa). If your SOA strategy is out of alignment with your business strategy, then you better fix one of them... it's probably going to be your SOA strategy.
On the other hand, if the two strategies are in complete alignment with one another, then any tactic taken to achieve either one should further the other strategy or, at a minimum, be neutral to it. That is, any tactic used to achieve your SOA strategy will never negatively impact the business strategy - provided the SOA strategy aligns with the business strategy.
This still leaves open the question of how to prioritize the short term objectives within a given strategy. More specifically, what measure do you use to prioritize the tactics used to achieve your SOA strategy?
So Dave, correct me if I'm wrong, here's how I should interpret your two statements:
With "resist the temptation to redirect resources toward tactical business needs," you were really saying to prioritize short term SOA objectives based on how much they benefit the SOA strategy.
But, when you later said "focus on short term objectives that are directly related to the generation of revenue," you were saying that, in bad times, you should redirect your resources to assist in executing short term business objectives, but prioritize which ones you address based on their net impact to the SOA strategy.
Did I get that right?
If so, while maybe we can agree you're not a flip-flopper, my perspective on prioritization is very different:
The business impact should always drive priority. Period. To me, any justification as to why you should ever prioritize based on the impact to the SOA strategy is backwards thinking. Why? If the business strategy doesn't meet its objectives, the success of your SOA strategy is irrelevant... unless your goal is to become a talking head, like me and Dave :-). Just make sure you know where your bread is buttered first.
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.