4

What work path do there exist to identify reasonable vertical slices of a classic n-tier platform code base and infrastructure (enterprise size)? Regardles of refactor or a new solution I think there will be the same approach (more or less?) So i'm primary interested in steps and definitioning of modules, functions, then "test" them into a function-unit or if it's appproved as a vertical.

To extend my thoughs..
I understand that a vertical should be a actor, a kind of business value. But is a communication system a actor, or a functional unit in a vertical slice? Probably yes And no (depends on enterprise), but how to decide? Is shipment a part of Order, or are both Order and Shipment different verticals?

What should a vertical slice consist of, to be a true vertical? In terms of Levels of functions, like "an own data store, an own client configuration tool, an own business intelligence calculation" and so on. Btw: It's a requirement that the verticals should be deployed and operatable independently of each other.

Maybe there is a kind of "yes/no" schema to use? "Is this X used for Y?" Yes - then it's a vertical. "Is this X used with Z?" - Yes, then it's anti-pattern for vertical. "Is X depend on the funtion YY?" If yes, then..

And so on. Links to success stories when define verticals is also of interest.

  • 1
    Please have a look through the faq regarding scope of questions. Your question is on-topic and likely constructive, but as phrased will likely require extremely long answers. Consider breaking your questions apart into separate questions so the community can focus and provide more direct answers. – user53019 May 10 '13 at 13:29
  • 2
    Good edit; focusing on a particular aspect will makes it easier to write an answer and not a whole book. Voted to reopen. – user53019 May 11 '13 at 12:52
  • Are you talking about the Scrum term? If so, it's really more of a project-management principle than an architectural principle. You wouldn't refactor anything, just define the minimum amount of functionality necessary to complete a particular user story (and there's obviously no formula for it, since it depends on the story; you have to figure out what the tasks are when you start work on that story). – Aaronaught May 12 '13 at 20:38
  • I have to understand the whole n-tier solution together with it's infrastructure, to define and propose useful SOA. To perform this, I also have to understand the boundaries of a SOA slice, in this case from a technical (developer architects) point of view and also some from a business point of view. – Independent May 12 '13 at 22:25
  • 1
    There is no magic formula nor an algorithm for this. Also some terminology doesn't add value at all. Here you have a link but it is all yada yada yada like anything you will find about "vertical slices" simpleprogrammer.com/2011/11/21/… – Tulains Córdova May 28 '13 at 19:47
3

Tackling a significant refactor requires you to have a solid understanding as to why you're performing that refactor.

I'll rule out the hobby level justifications such as "make the code more pure" or "improve stylistic expression" or similar. Those aren't bad justifications, but a commercial project will almost never see or use that level of justification for a major undertaking.

In contrast, commercial level refactoring justification always involves pain.

  • "Maintenance has become impossible."
  • "The code base can't be extended."
  • "Code changes generate obscure errors in unanticipated areas of the code."

Pain justifies the expense and risk involved. And pain leads you to your answer. You refactor in order to minimize future pain. Refactor in order to encapsulate the change.

You mentioned a couple of aspects such as communication systems, orders, and shipments. And you correctly called out that there isn't a one-size-fits-all approach to identify what belongs where. Every system is different based upon its domain and business need.

For your system, identify what is changing. Push that into its own vertical that conforms to a contract or an API with the rest of the system. Whenever that section changes, you can verify it still meets its contract and control the amount of damage from the code change.

1

The correct way may not be strictly horizontal or vertical, but wavelet:

http://www.mathworks.com/help/wavelet/gs/ch01_intro42.gif

Scale-time decomposition diagram in wavelet analysis

  • X-axis: functional units of an enterprise (Order, shipment, etc)
  • Y-axis: the layers of software architecture (database, transactions, message queues, services, web-services, front-end)

The key is to build the lower-level layers of software in a highly-reusable way, and easy for the higher-level users, so that the developers of the higher layers do not need to spend too much time redoing what the lower-levels ought to be doing.

The advantage of the reusable lower-levels can be extended beyond software programming - configurations, virtual-machine images, software licenses, and even hardware specifications (or even standardized server machines) can all be designed with reusability (by multiple business units) in mind.

The higher layer may need to talk to multiple functional units to get things done.

Consider the issue of customer support in your example.

  • If there is a problem in the Order system, the customer needs to be contacted.
  • If there is a problem with Shipping, the customer also needs to be contacted.

The blog post http://simpleprogrammer.com/2011/11/21/understanding-the-vertical-slice/ suggested by @user61852 talks about writing new software. When taking the vertical slice approach, one tries to satisfy a small facet of functionality requested by a single functional unit, by implementing the smallest amount of software.

  • Example: If shipping needs to talk to the customer, they will only be given an extension number to the customer representative department and a customer ID. Someone in the shipping department needs to do this manually.
  • In the future, it may be integrated with Skype, but that's the long future.

The blog post implies the use of a lot of mock-ups, throw-away UIs, and prop-ups (imperfect way of meeting part of functional requirements) while a more endurable implementation is scheduled later in the project.

The blog post does not talk about refactoring an existing enterprise software system.

As @GlenH7 implies, if it's working, don't make risky changes to it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.