--- In [email protected], "Udi Dahan" <thesoftwaresimpl...@...> wrote: > > In my view of business services, applications are NOT necessarily > replaced, but are a part of a business service.
Sure, traditional applications may be used as part of a service implementation. > Some applications are problematic in that they contain > functionality under the responsibility of multiple business > services. Applications like "the portal", or "the database", > or "the ERP" often fall under that category. Sure. No confusion there. Even after an SO effort, there will potentially be "new" applications that aggregate multiple services into a cohesive whole to be used by users, would you agree? > While the refactoring effort may prove to be difficult, the > applications still continue to exist afterwards. We seem to agree here. Some apps will exist as service implementation platforms. Other apps will be the front-ends of services. The UI app interacting with multiple, independent services to do the work directed by a user. > Let's take a closer look at what complexity is. On the one hand, we > have these apps which are likely to be monolithic big piles of mud > with very high internal complexity. After performing the SO > approach, we may have more moving parts, yet each is better defined > with much lower internal complexity than before. Sure. We despise the monoliths. Let's break them up. And reassemble things in new ways. And structure components such that reassembling in new ways is easier to do. Lower internal complexity would seem to be an assumption. > If we were to look at the average complexity of the before and > after, we see that it goes down substantially. There are many > metrics that can be used to prove that (cyclomatic complexity, for > one), but the KPI we see improving is the time it takes to make a > change or add functionality to the ecosystem. Does anyone have anything other than anecdotal evidence of complexity decreasing "substantially?" > Yes. That actually means that more people can work on more parts at > the same time rolling out more business functionality faster. In > short, that's a good thing. That's one of the benefits of busting things up--and the pro that offsets the con of increased complexity. I see what you're saying-- but let's not gloss over the complexity aspect of more people working on more parts at the same time. IMO, an increase in complexity is a given for an SO environment. This increases the emphasis on the need for architectural discipline and good engineering and management practice. For example, instead of dealing with the version update of 1 application, we have to consider multiple services. The impact of a change, which may in the past be isolated to a single application, now needs to consider all consumers, which may not be known (depending on management/tracking rigor). Changes to interfaces will now encompass versioning more often than as been done in the past. Keeping complexity and redundancy minimized are definitely worthwhile goals. IMO, SO approaches *tend* to increase complexity so we need to stay on top of it and manage it well. As always, just my 2 bits. -Rob
