Custom Business Application Definition

There has been some heated disagreement over the definition of "custom business application" (CBA) on this wiki. This is an attempt to document at least working definitions to serve as reference points. (CBAD = Custom Business Application Developer)

Working Definition/Rules #1 (DRAFT)

Generally involves a fair amount of CRUD (CrudScreen) and database interaction.
Built by or targeted for developers who are generally considered interchangeable with regard to either one of:
- Other external CBA developers's
- Internal CBA dev's from other areas of the same org who know the general domain of the organization.
- (Whether it's good or bad, the industry wants PlugCompatibleInterchangeableEngineers/developers.)
Do not depend heavily on the programming of domain specialists, such statisticians, mathematicians, GIS experts, AI experts, physics experts, embedded programmers, etc.
Generally use programming languages that emphasize code maintenance and coding cost over machine performance. These include:
- Java
- Microsoft Dot.Net stacks, VB, and MS-Access
- Macromedia/Adobe tools/languages
- "Web languages" like PHP
- CRUD-centric languages: PowerBuilder, Oracle Forms, Delphi
Excludes SystemsSoftware
Generally involves algorithms and techniques that non-specialized management can relate to. For example, some AI-based algorithms are not going to make sense to a typical manager.
Most of the "volume chomping" or "heavy looping" (or equivalent) is done via an RDBMS, and NOT application-code high-volume loops processing RAM-based data structures.
A domain specialist's resume will generally have about half or more of their org-targeted resume geared toward the domain itself and not just IT.

I realize this isn't water-tight. It's just a "gist" at this point. "GUI specialist" is kind of a gray area. Mastering the top of the HtmlStack is sometimes a dedicated specialist because the stack sucks. Most internal apps don't stretch the HtmlStack to the limit such that a general CBAD can usually handle those. But public-facing sites sometimes need a Web-GUI expert to get the HtmlStack to work right. (Some start with a generalist internal CBAD, but as the bugs and glitch help-desk tickets pile up, they then turn to a dedicated specialist, or back away from desktop echoing - BrowserAbuseSyndrome.)

Some have suggested "anything that's custom", but would make a commercial rocket scientist a CBAD, which goes against what I believe is the industry's usage pattern. When the "specialist-ness" over-powers the "business-ness", then I exclude it from CBA, if that makes any sense.

I would also note that many colleges and universities split their development oriented degrees into something akin to "Computer Science", and "Management Information Systems". The second tends to be geared toward CBAD. I don't see any other common large-scale division used by the schools.

--top

Candidate Definition #2

CBA is a model of a business operation or task that attempts to mirror the domain knowledge of the domain expert(s) (or at least those you pay you). It's essentially "head modelling".

Note that this differs from work with "standardized ComputerScience algorithms" (SCSA) often talked about on this wiki by select WikiZens in that domain experts generally don't understand them. They want a model that they can relate to for reasons described later.

Sometimes CBA's will integrate with SCSA's, especially for searching where "perfect" matching is not necessary. By perfect matching I mean that specific results are always expected and the business depends on them working reliably. For example, if I know that customer 4723 exists yet a prompt that asks to enter customer ID cannot find it, the customer won't accept it. SCSA's are usually used to obtain "bonus" behavior or results, not mission-critical operations. Mission-critical operations usually need trace-ability in a way that the domain managers can understand. In other words, the steps are processed, categorized, and documented in such a way that "non-techie" domain experts can relate to. "It didn't find a match that time because Google was garbage collecting and so exceeded the time threshold given" is not acceptable for mission-critical.

An exception is if "mission critical" is defined in terms of volume more so than accuracy. Free web services that rely on ad revenue are often such an example because if going from a 2% failure rate to a 1% rate costs them 30% more, they may skip the improvement because it's less profitable.

If an employee shift scheduling algorithm A is only 90% as accurate (close to theoretical optimum) as algorithm B, then the manager/customer may still prefer A over B because A is "trace-able" in a way they can understand. Managers often have to justify the scheduling results to their superiors and perhaps the employees being scheduled such that less-than-perfect-but-explainable results are often preferred over theoretically more accurate results. Whether this phenomena is "good" or not is hard to say. It does appear to be a case of SovietShoeFactoryPrinciple. (Related: MakeSummariesTraceable)

Domain-level explain-ability is generally what the market wants in my experience and as a developer I'm expected to cater to it or hit the road. Perhaps with some experiments one can demonstrate that B is really better than A, but it requires some careful salesmanship. Remember, that even if you can convince one manager of B's superiority, they know they still have to explain results to other personnel and will thus want careful and legible documentation of the trade-offs: losing specific-case explanability in trade for generally better average results. -t

Discussion on Definition #1

Essentially, your definition covers record-keeping, reporting and accounting. This category of applications was driven to industry prominence in the mid 1980s to early 1990s by the rise of PCs, PC spreadsheet software, and dBaseIII (plus its clones) which made it possible for fairly non-technical domain experts to produce applications with relatively little technical effort. Whilst it's still an important category of applications, the ever-increasing desire for increased automation, scalability, flexibility, interoperability, and extended functionality has largely driven the programming and technical side back into general software development, while the non-technical aspects are handled with end-user computing -- spreadsheets (mainly) and desktop databases (a little).

It has almost nothing to do with PC's. I did CBA's on a DEC VAX. And of course there is COBOL.
It has almost everything to do with PCs. Prior to PCs, application development of all kinds was application development, done by professional programmers. It was the adoption of PCs that created a largely non-technical, non-professional-programmer class of developers who first made Visicalc spreadsheets and dBase II applications, and later Lotus 1-2-3 spreadsheets and dBase III applications. Now they make Excel spreadsheets and VBA applications, and they focus on record-keeping, reporting and accounting.
Spreadsheets are NOT used for high-end record-keeping, reporting and accounting. They are designed for business scenario modeling. They can be used for the other things, but if so, programmers are typically not involved, at least until something more robust is needed. dBase evolved from a mainframe product called RETRIEVE, by the way.
That's right -- spreadsheets are not used for high-end record-keeping, reporting and accounting. They're used extensively for end-user record-keeping, reporting and accounting. I.e., the low end. The high end is handled by professional programmers. dBase did not evolve from RETRIEVE, it was inspired by the user's manual for JPLDIS, which evolved from RETRIEVE. Look it up.
What does end-user tools have to do with your statement? It's not about PC's.
PCs drove end-user computing, and what you've been calling "custom business applications" are low-end record-keeping, reporting and accounting applications primarily created by designated end users rather than programmers. Notably, the mass of dBaseII and dBaseIII developers that blossomed in the 1980s were rarely full-time programmers with ComputerScience, EE or maths degrees; they were usually administrators, former middle managers, and small-business owners.
And saying humans evolved from worms is not wrong if they also evolved from amphibians. Thus, your RETRIEVE complaint makes no sense.
In Wayne Ratliff's own words: "dBASe's relationship to Jet Propoulsion [sic] Laboratory Data-management and Information System (JPLDIS) is also frequently misunderstood. I wasn't a part of the JPLDIS development team. I didn't use the JPLDIS source code to develop Vulcan/dBASE II. I don't consider Vulcan/dBASE II a derivative of JPLDIS. I do acknowledge that the X-Base language incorporates a sizable portion of JPLDIS command syntax, but the Vulcan/dBASE II and JPLDIS computer programs are totally different. JPLDIS is actually a rewrite with enhancement of Tymshare Corp.'s RETRIEVE system." (http://www.accessmylibrary.com/coms2/summary_0286-9229460_ITM) I'll take "I don't consider ...dbaseII a derivative of JPLDIS", where JPLDIS was a rewrite of RETRIEVE -- from the author himself -- as a fairly definitive indication that dBase did not evolve from RETRIEVE. It was, at best, indirectly inspired by RETRIEVE.
He appears to be talking about the engine code base, not so much the nature of the ExBase language in terms of ExBase programming. I've seen a mainframe RETRIEVE manual with my own eyes, and the language does heavily resemble dBase/ExBase. As I remember a write-up about it, JPLDIS was created because the cost of RETRIEVE and similar tools was considered too high, so they essentially cloned the concept, but with different key-words. The link you gave makes it clear that JPLDIS heavily influenced dBASE. Sample quote: "I never felt any particular need for Vulcan to exactly emulate JPLDIS, but I usually only changed things when it was necessary or convenient." That link doesn't really address the origin of JPLDIS itself. -t
Implementing even the same language doesn't imply implementation A evolved from implementation B. PostgreSQL didn't evolve from DB2, for example, and neither evolved from Oracle Database.
Why does this matter to this discussion? App developers using dBASE couldn't even see the engine code-base. It's a trivial difference here whether the engine code-base came from JPLDIS or was re-written. Purchasers judged it for the app language and features, NOT the engine code-base; for that's invisible to them. I'm not referring to the "evolution" of the engine code-base.
It doesn't matter to the broader discussion, but I'm addressing your claim that dBase evolved from RETRIEVE. I usually see that claim used in an attempt to give xBase more legitimacy than it deserves.
It did evolve from RETRIEVE because JPLDIS evolved from RETRIEVE and dBase evolved from JPLDIS. Note that "evolution" doesn't necessarily mean "gradual improvement". Saying it evolved from something by itself is not a claim of quality either way.
Looking at a manual for inspiration isn't an evolution, it's at best a derivation.
It *is* a derivation.
A distant one at best, like reading a book about cars and being inspired to make a rollerskate.
No. I saw an actual RETRIEVE manual.
xBase might use RETRIEVE commands, but it wasn't RETRIEVE. Not by a long shot. It just had some of the same commands.
It had the "essence" of what makes ExBase different than other languages. I realize a lot of specialized commands were added to say draw color boxes on Wintel machine VGA screens, etc., but that's just side trivia to me.
What is that essence?
We are getting off topic. I don't see how answering this would settle anything.

"Rocket science" and "custom business application" may have been clearly delineated in the 1990s when the accounting department received the engineering department's rocket fuel consumption estimate on paper, but now the fuel consumption estimation applications are expected to push data in real-time to the accounting applications, and the accounting applications feed back to the fuel consumption applications -- perhaps over an EnterpriseServiceBus, perhaps via RESTful interfaces, perhaps via shared databases, and so on. What your definition really highlights is that some developers still focus mainly on record-keeping, reporting and accounting. However, other developers focus on that and/or other things. All are working on custom applications for business.

The fuel consumption would probably be tracked via an RDBMS. The rocket may update such in real-time, but there will still be reporting and CRUD associated with fuel tracking.
Could be. Like I said, "rocket science" and "custom business application" may have been clearly delineated in the 1990s, but now the boundaries are blurred and the expected technical sophistication of all custom applications is, in general, increasing.
I'm not sure I agree with the "increasing" claim. The web has made it easier to find pre-packaged solutions such that there is less reinventing.
How the applications are built (such as by integrating pre-packaged solutions) is orthogonal to both their requirements and their underlying technology.
Software is expected to do more, but there are also more tools and options available to do it.
Indeed, and it is precisely the complexity of successfully using and integrating such tools that is pushing general application development back into the domain of highly-technical programmers. However, day-to-day record-keeping, reporting and accounting will remain with end-users and programmers of relatively limited programming capability. By that, I certainly don't mean to disparage those who do it -- it's highly-skilled work in terms of domain knowledge -- but such developers are rarely of the same programming inclination and calibre as those who develop domain-specific languages, highly-customised or fluid GUIs, mobile applications, Web apps, distributed applications and so on.
Yes, "specialists", such as UI specialists who know how to make cutting-edge bells and whistles. In almost any industry, specialists are paid more and have more training and experience in their specialty. There are generalist doctors and specialist doctors, and the specialists are almost always paid more. (Specializing has its down-sides, career-wise, but that's another topic. I'm not going to get into an "elitism" battle here.) By agreeing there is a general bifurcation between generalists and specialists, you seem to be backing my point.
I don't disagree that such a bifurcation exists. I disagree that record-keeping, reporting and accounting is generalist. It's another specialism. The generalist is the programmer who can work today on database-driven Web apps and tomorrow on language parsers.
They are "business generalists", not general generalists. There are common patterns to most businesses and organizations that can be grouped together into a "big niche" with a fairly clear identity. Maybe we have the name wrong, but there is a general pattern and general distinction regardless of whether it's called CBA, Management Information Systems, or CRUD-centric-development.
Something that's in the category of "not general generalist" is, by definition, a specialist. There are indeed common patterns that can be grouped into a "big niche" with a fairly clear identity. My issue is with the vague name. Numerous disagreements have been sustained on this Wiki over what "custom business application" means. It's because when "custom business application" is used, you're thinking of the last data entry and reporting app you wrote in PHP, but your correspondent is thinking of the custom sales forecasting system he wrote in Haskell. They're both "custom business applications", but very different. With little effort it's easy for you to think that "custom business application" == "data entry and reporting" because that's what you do, whilst your correspondent thinks "custom business application" == "financial statistics" because that's what he does.
If his/her specialty is "financial statistics" then it's a specialty of "financial statistics". My working definition generally excludes such specialists because they are not interchangeable with other CBAD's who are not specialists in financial statistics. Again, you are allowed to create your own working definition for clarity and you can refer to it as "CBA working-definition #2". We don't have to fight over a OneRightWay? definition in that case. I don't want a needless LaynesLaw battle. And the practical reason I generally exclude such examples for analysis on this wiki is because they require another specialist to evaluate things such as future change plausibility for given features. If somebody says, "look how easy it is to plug in a new forecasting formula just by adding a new HOF!", neither I nor readers can know if that change pattern is realistic and common. Some of the change-pattern claims look highly fishy to me, but I don't know enough about the domain to explain why they are unrealistic and unlikely.
And if your speciality is "data entry and reporting" then it's a speciality of "data entry and reporting". Interchangeability only exists in data entry and reporting because any programmer -- and a fair number of non-programmers -- can do data entry and reporting. Not every programmer has the ability to do financial statistics. Your notion of avoiding certain categories of example because they require specialists is a peculiar one. Are you unable to generalise your examples so they can be considered in abstract? Or do you consider every case to be a special case?
If "any programmer can do it", then it's not really a specialty, or at least far less specialized. (Note that doing it and doing it well are not necessarily the same. Newbie CRUD designs are often clunky and confusing for users. It's somewhat comparable to home repairs: a lot of people are capable of doing their own, but probably take far longer than somebody with experience and training, and are more likely to make a hard-to-undo mistake. One develops a "horse-sense" of human office behavior and likely future change patterns of a given business.)
It's less specialised in terms of programming ability, but just as specialised in terms of being a niche and requiring domain knowledge.
And yes, every case is special. I wish it was as easy as plugging in HOF Legos into the existing pattern/framework, but that's a pipe dream in CBA. I thought there was at least partial agreement to this near the end of HofPattern.
That you think what's been described is some notion of "HOF Legos", then you're not understanding HOFs. And, perhaps your view that "every case is special" is part of why there is so much disagreement between you and so many others here. Programming is very much about finding generalities and coding to them, then fitting individual cases into the generalities. The more this can be done, the more code can be re-used. If you are fundamentally opposed to this philosophy, or choose not to recognise it, then you will perpetually be at odds with the people who apply it consistently. As for the end of HofPattern, I agreed only that the bulk of data entry, reporting and accounting code probably benefits little from HOFs, unless you're trying to create a fluid, concurrent, or highly customised interface. For basic data entry, reporting and accounting, all the heavy lifting has been done for you in tools designed for this, like MicrosoftAccess.
I'm perfectly open to new abstractions that work, but I haven't seen anything that's practical. Show some realistic scenarios and I'd be happy to adapt the ideas. I love magic bullets. Most successful abstractions in CBA seem to be smaller in scale. Those that are too big become too inflexible when enough exceptions to the rule come along to gum them up. EightyTwentyRule has killed a lot of abstractions I've tried over the years. There's a lot of nitty-gritty interweaving of entities/concepts in CBA's such that designs that assume "clean" isolation can easily become a bottleneck. The cell walls need to be semi-permeable or else we spend most of the code managing complex and/or bureaucratic GateKeeper interfaces. -t
Note that your perception of what abstractions are successful in a given domain may differ from other's. This is dependent both on the specific problems you face and the way you approach problems in general. Where you find little opportunity for abstraction, someone else may see much opportunity. And vice versa, of course.
- That's why I'd like to see realistic CBA examples of HOF's improving source code. I don't claim that I know everything, only that YOU have not made a case for widespread HOF use in CBA's. You are insistent that they are so grand in CBA's, but fail to produce scenarios. I don't understand why you are unable to produce. It baffles me. If you have such a strong conviction, it implies you've done it enough times to know it's useful and common, and thus should have vast hands-on CBA experience using HOF's, yet you cannot translate that experience into realistic CBA scenarios and UseCases where HOF's clearly help. You keep leaning toward machine speed and fitting specific UI clients.
- See HofPattern for a realistic example that isn't GUI-specific.
- Sorry, I missed it. Supply bookmark names or something, please.
- Top of the page. The "indivisible algorithm", e.g., employee scheduling, logistics routing, injection of logging mechanisms, etc.
- Use a CASE list instead, as described. You imply case lists are somehow fragile. They are not unless you are Michael J. Fox without his meds. I doubt there is a need to keep adding yet more functions because the managers have to understand what the algorithms are, and they are not going to want 30 different scheduling algorithms. The work world doesn't work that way. They'll settle a few they are comfortable with and almost rarely add a new one. (There may be parameter/setting variations, but this is not part of your pattern.) Thus, your "mass new HOF factory" is likely a myth. You are exaggerating a certain change pattern. It's as unrealistic as your sort comparer HOF injecter. It's a nice "lab toy" example, but doesn't fit real world change patterns. If you claim 30 is realistic, then describe all 30 of them to prove it! Otherwise I call "hogwash".
- CASE lists are fragile because they require modifying the algorithm code every time a new implementation of the algorithm is needed. Only one algorithm implementation may be needed per application, but there may be many applications that use the same algorithm. That could practically mean recompiling a DLL or library for each new application that uses the DLL or library. Is that reasonable? The same applies to the canonical C/C++ sort() implementation. Should we have to recompile the C standard library for each application that needs sort()? As for parameter/setting variations, that is covered in my example on HofPattern. See the part that starts, "Now what if we need to customise based on some dynamic data, i.e., we require a data-dependent series of customisations?"
- Continued at SwitchCaseListVersusHof.
MicrosoftAccess has a lot of flaws.
So do most things.
And that's why your suggestion that Access cornered the niche is incorrect. Many CBA apps don't work so well under the Access model. For one, users want more web-based apps these days.
Access was the successor to xBase and it's used heavily used to create in-house applications, especially by non-technical end-users. (Though its use is probably marginal compared to the number of end-users who leverage Excel to create "reports" and "programs".) Of course, when xBase was in its heyday there was no Web, and custom applications certainly target the Web, but for in-house custom record-keeping enterprise environments like SAP are probably more pervasive than, say, general Web development in PHP.
I'm not sure what your point is. I agree that MS-Access replaced much of the niche of ExBase (largely because xBase failed to get GUI's right). Access is used by both end-users and app developers, just as ExBase was. But MS-Access doesn't work so well when you have more than a handful of end-users in the same room because it's easy to "break" it by pressing a wrong key. (There are ways to "lock it down", but that in itself takes relatively careful study.)
Access was an example of an environment where the heavy lifting is done for you. As above, "For basic data entry, reporting and accounting, all the heavy lifting has been done for you in tools designed for this, like MicrosoftAccess." There are other tools that have done all the heavy lifting for you, like CrystalReports and SAP.
Access is "heavy lifting"? The niche of both xBase and Access in mid 1990's was approximately a CRUD-ish app with no more than about 200 "write" transactions per average day, contains a total of less than a half-million table records, and was not "mission critical", meaning if it broke, it wouldn't significantly slow the primary and immediate business functions. (True, organizations often used the wrong tools for the job, creating risks. Also, they were indeed often used by power-users to create their own apps or queries. But us IT guys usually didn't get involved with those unless they wanted to formalize the app or moved on and "orphan" it to us.)
I used "heavy lifting", above, to refer to the fact that Access has done all the underlying systems programming for you (that's the "heavy lifting") to support basic data entry, reporting and accounting -- by providing GUI widgets, reporting tools, form painters, a lightweight DBMS and external DBMS connectivity, a scripting language -- so you don't have to write them or integrate them yourself.
Yes, CBA's rely heavily on the kinds of tools described in StandardToolDependency?/StandardToolDependancy.

Therefore, it would be more accurate and less contentious to call this category "record-keeping, reporting and accounting" rather than "custom business applications." It would probably provide a more focused topic for discussion, too.

What the human brain does could be called "record-keeping, reporting and accounting". That's not very specific.

The human brain also does logical inference, semantic searching, introspection, pattern matching, symbolic processing and model construction, all of which have programming equivalents. (Plus consciousness, which doesn't yet have a programming equivalent.) So, "record-keeping, reporting and accounting" is specific enough and certainly more specific than "custom business application", which is a sufficiently broad category to incorporate (as it often does) logical inference, semantic searching, introspection, pattern matching, symbolic processing, and (automated) model construction.

And CBAD will often incorporate these kinds of things into CBA's. It's just that if any one becomes the overriding factor such that an X expert is required, then it no longer falls under CBA, at least as the primary category. It becomes an "AI app" instead of a CBA, for example. If you don't like my working definition, fine, but that doesn't make it's "wrong". You are allowed to introduce your own working definition.

Your definition is further evidence that what you really mean by "CBA" is "record-keeping, reporting and accounting". The former implies no restrictions on what an application may be (other than a "custom application" for "business"), but the latter does and seems to accord well with examples you've given on this Wiki over the years. For example, it explains why your CampusExample is defined in terms of a database schema rather than requirements, or why you feel ReportQueueExample is useful. In record-keeping, reporting and accounting, the schema is of primary importance.

One thing that should also be considered is managers' ability to comprehend what is going on. It's best that outcomes or output be trace-able to business rules that managers can also understand and that the "steps" be tracked and reportable. Thus, just about any non-trivial project will become about what you appear to call "record-keeping and reporting" because the biz rules should ultimately be tracked and reported in a way that MBA-style managers can analyze and relate to, not just developers. This often limits the complexity of the algorithms used, for good or bad. Thus, almost any non-trivial process is going to have a CRUD-ish component to it. My working definition should probably reflect this.

Almost any non-trivial process will certainly have CRUD-ish components, but record-keeping, reporting and accounting is composed entirely from CrudScreens and reports.

Now there are industries such as search (Google) where the line-of-business algorithms are beyond what a typical MBA manager will be able to relate to. But such orgs are generally run by technical managers or specialist managers. In the oil biz, many of the managers will be trained geologists promoted to management, for example. Such geologist programmers and geologist managers are not "business developers".

They're certainly oil-business developers.

And rocket science developers are "rocket-business developers"? What does that give us over "rocket industry developers" or "space developers"? We could call it many different things.

And therein lies a big part of the problem. Broad terms are largely unhelpful and lead to arguments. That's why I suggest being more specific, and using "record-keeping, reporting and accounting" to identify what you mean by "custom business application".

If we can emulate a brain using tables and some basic "node" processing rules:

http://grault.net/adjunct/index.cgi?BrainSchema

Then human thought can be viewed as "record-keeping, reporting and accounting".

"If we can emulate a brain using tables and some basic "node" processing rules..."

We can't.

Why are you so sure? (Another topic?)

Trivially, because sets of tables and rules are static. Something needs to computationally apply the rules to the data in the tables. Also, we need to know what rules. What you appear to be suggesting is (partly?) an artificial neural network. Artificial neural networks are good for solving certain problems, but we don't know that we can emulate a human brain with one.

The "rules" for processing neural networks are also static. It's the connections and weights between them that change. The electrochemical "rules" of brain cells are pretty much the same from birth to death. It's true we don't know for sure how the brain works, but based on existing knowledge, a neural network model is a sufficient model (with some minor tweaking in the model for hormones perhaps).

Ok, build one.

The general point is that one can build a TuringMachine using "record-keeping, reporting and accounting". It doesn't cull the total set of all applications.

It's an interesting question if one can build a TuringMachine using a "simple" neural model with some kind of periodic input event(s) to trigger propagation cycles. I'm pretty confident it can be done, but don't want to try at this time being I have other toy projects to finish. -t

I'm not sure what that means. Regardless, "record-keeping, reporting and accounting" clearly refers to a specific category of applications -- particularly the category you apparently work in. "Custom Business Application" does not. It appears that when you use "custom business application", you're probably thinking of the last record-keeping, reporting and accounting application you worked on. Your typical correspondent, however, might think "custom business application" means the last financial forecasting application he worked on. This confusion can be reduced or eliminated by avoiding "custom business application" in favour of "record-keeping, reporting and accounting."

That's 3 different things. I don't consider that a magical grouping other than they are fairly often related. A financial forecasting application would generally be done by a programmer with a decent knowledge of finance, not a "generic" CBA. I would classify your example as a "custom domain application(s)".

Beware of proliferating terminology without adding clarity.

Defining topics with fuzzy boundaries is never an easy thing.