Start a Discussion
SOA
user-pic

Is SOA Ever a Tactical Discipline or is it Always Strategic, But Mapped into Tactical Requirements

Vote 0 Votes
JP Morgenthal: I had a comment from a reader that stated: "At the project level, where BAs operate, SOA is a tactical discipline that belongs in the hands of the technical team." The question is, "Is SOA ever a tactical discipline or is it always strategic, but mapped into tactical requirements?"

Reminder, next week Wednesday ebizQ's SOA in Action Virtual Conference begins.  Sign-up here!

14 Replies

| Add a Reply
  • For the record, my stance is that it is ALWAYS strategic and mapped into tactical requirements, which means that your software engineering efforts are guided by the SOA design, but the effort itself is not SOA. In the latter case I prefer to use SODA as a term to differentiate the strategic and tactical efforts.

  • Since the whole premise of SOA is based on reuse and commonality across the enterprise, it has to be strategic in perspective. Achieving it however is done through inserting the concepts, discipline, mindset and checkpoints in tactical implementations. Overall, too much focus on strategy is going to have failed results and inability to deliver tactically impreative initiatives on time. On the other hand, too much focus on tactical focus is going to most likely result in missed opportunities across projects and programs to leverage re-use and utilize SOA to it's fullest. So the trick is to maintain a healthy balance between strategic direction with tactical imperatives. Easier said than done, but good governance based on experienced and practical architects is usually what makes or breaks the process.

  • I agree with both JP and Vishal - SOA effort has to be aligned with a long-term plan to deliver benefits. However those benefits can only be obtained, realistically, project-by-project. The trick, as Vishal says, is to take your strategic goals and make sure that every project / step along the journey applies the SOA principles to get you closer to your goals.

    I'd add a little extra to Vishal's good point about governance and architects: both those things need to have strong mandates behind them, or else individual project teams will invariably find ways to take shortcuts whenever it suits short-term ends.

  • Here are my 2 p.

    Business requirements that are considered in the project in IT do not come from the blue, they have to be either tactical or strategic business requirements. In both cases, they MUST adhere to the Business Strategic Plan of the enterprise. That is, Service-Oriented Solution can be tactical or strategic, but this depends on the Business perspective, not on the IT or project perspectives.

    Returning to the initial question, who is that BA – Business Analyst or Business Architect? If it is a Business Analyst, it is not a surprise that this person does not see (does not need to see) behind the project scope. The project is always tactical while the programme is strategic in the most of the cases.

    I would concur the statement “Since the whole premise of SOA is based on reuse and commonality across the enterprise?. This is obsolete ‘premise’; in Business, SOA is not about reuse and commonality across the enterprise because there are many reusable functions and feature in Business (if it is built properly); instead, the premise of SOA is in the business flexibility in adopting business changes via re-composition of business services (functions, features, processes). We will have all the confusion illustrated by this discussion question until IT would think it does something different from Business and ignores business nature of Service-Oriented Architecture.

  • Sorry, I have meant "...there are NOT many reusable functions and feature in Business"

  • SOA is an architectural approach and like any other architecture it needs to be looked at from a strategic point of view and the tactical approaches are mostly transient in nature.

    The key is whether SOA (“the architecture?) is aligned with the business objectives!

  • I believe SOA has value both as a strategic and a tactical tool. Obviously the best value is achieved through a strategic policy to implement a SOA, however, to achieve tactical goals, using a standards based SOA implementation can significantly speed up any project even if an organization has not committed at a strategic level to SOA.

    We all know that agreeing a strategy in any organization takes long enough while implementing such a strategy can take nerves of steel as it there will be pitfalls along the way. We prefer to recommend to people that they implement working versions of SOA in a small way to illustrates the benefits to support the implementation of a strategy. We have a number of papers on this approach here here. Ultimately I would suggest that this is a tactical approach with a view to encouraging the adoption of a SOA Strategy so they go hand in glove IMHO.

    • John,

      At the risk of seeming combative, I noticed that you were a vendor of a tool that you call SOA Gateway. I can't help but to think that there isn't a vendor out there that wouldn't reinforce your stance that SOA is tactical, given that it is a requirement for SOA to be tactical in order for you to sell a product related to SOA. I believe vendors have had a devastating effect on SOA in the industry because of this perspective, and don't mean to call you out specifically, but it needed to be said. Vendors are trying to sell integration products, middleware and data management products branded with an SOA tag without any relevance to SOA whatsoever other than unknowing consumers buy into the flip side of the equation and want to say that they are doing SOA, when they are merely doing EAI or distributed application development.

      JP

  • Embarking on a successful SOA initiative depends on how well it is carried out and adopted by the organization. This means that certain processes and practices must be adhered to in order to ensure that those responsible understand what is expected of them, when it is expected and how they can supply the necessary artifacts.

    Alleviating this risk means utilizing a foundational methodology for delivering solutions to meet strategic goals and tactical plans while moving up the Service-Oriented Maturity Model (SOMM).

    I believe you are at risk if you look to do one without the other. If it makes you feel better then create the tactical plan and map it to a strategic goal or visa-versa just be sure to include both the business and IT folks.

  • Since SOA first entered the popular lexicon, there’s been a debate as to not only how to define it but also whether to tag it as “strategic?, “tactical? or some combination.

    First, I think it helps to agree on the difference between strategy and tactics before engaging in the debate. I would wager that many of us have been in professional venues in which someone has said, “we need to be more strategic? or “that’s too tactical? and everyone nods their heads but rarely reaches a consensus in defining a strategy and an associated portfolio of tactics.

    To help clarify the difference, I reference the book, "Being Strategic," as the author gives a simple and useful set of definitions which I modify somewhat for my professional work. Strategy is defined as the “core directional choices that will best move you toward your desired future.? Tactics are the “specific actions that will best implement your strategy.?

    Second, we need to agree on a definition of SOA. I contend it’s an architectural style that leverages certain principles (e.g., reusability, loose-coupling, etc...). It’s not an approach, process, methodology or technology.

    With these definitions in mind and assuming your desired future is one in which your organization is agile, flexible and able to orchestrate business processes on the fly, then I would contend that SOA is strategic, in that it provides a set of core direction choices.

    For example, those choices include but are not limited to characterizing your business as a set of business processes capable of being enable by one or more software services; defining a standard set of service interfaces (e.g., WS*, CORBA, etc…); establishing a common set of service integration patterns (e.g., ESB, service-to-service, etc…) that will you toward your desired future.

    The specific tactics would detail the core directional choices. For example, with regards to a common set of service integration patterns, a strategy could be that the organization will use one (1) ESB to integrate its applications and services. Or, an alternate strategy could be that the organization will use a federated ESB approach. Once that choice has been made, the set of actions (e.g., research the ESB space, select an ESB vendor, establish ESB governance, design the ESB, deploy the ESB, etc…) to implement the ESB are the tactics.

    I think we debate the “strategy? vs. “tactical? issue because the tactics (actions) are SOA flavored – i.e., in the case of the ESB example above, we would leverage SOA principles in designing our ESB. However, I think if we think of strategy as core direction choices and tactics as actions and the details associated with our choices, we have suitable framework in which to distinguish the two with respect to SOA.

  • SOA is an Enterprise Architecture therefore it is always strategic. However, the initial SOA efforts may started as tactical assignments. The balance between strategic SOA and mapping it into tactical requirements is delicate. It is easy to loose it by too many uncoordinated tactical efforts, as well as by too big strategic approach which is not mapped properly to tactical tasks. It should be noticed that strategic Top-Down SOA is different from Bottom-Up Web Services. The balance is achieved by pragmatic approach Top-Down and Bottom-Up.

  • SOA is ideally formulated as a strategic approach, but this may be a hard sell for SOA proponents. Thus, its likely to start at a tactical level, as "Guerilla SOA," addressing one pain point at a time. Eventually, these islands of SOA will be federated into a strategic approach.

  • Good lively discussion... Just to add one thought.. remember, what gets measured gets done. Assuming most organizations will have strategic goals around the adoption of SOA, what benefits it will bring and what is most important to the organization and then operational strategies to apply SOA in tactical projects, the ability to measure and reward those involved will be key.

    The strategic goals of SOA may get lost in tactical execution if the teams executing are not measured on their ability to design, develop, test, deliver and operate in accordance with the goals of the SOA. The teams need to understand and know what is expected of them, how to validate that they are complying and that the impact of compliance/non-compliance with SOA goals will have a material impact on the viewed success of their tactical project. Too often, I've seen strategy well defined but lost in translation when it gets down to actual execution "in the trenches".

  • Excellent Discussion, My 2 cents.

    I feel that the planning aspect of SOA be strategic and implementation aspect be incremental and tactical.

    I also agree with Michael Poulin on the basic premise "the premise of SOA is in the business flexibility in adopting business changes via re-composition of business services (functions, features, processes)".

    When I meant strategic SOA planning, I meant future state architecture definition be done with a holistic perspective and supplement it with incremental and tactical approach to implementation.

    One type of the tactical implementation can be moving from current state to transition state (converting and reusing existing data/logic) so that it can be seamlessly transformed to future state(once the future state capability is made ready).



Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT