We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
Web 2.0
user-pic

What's the Difference Between Situational and Nonsituational Applications?

Vote 0 Votes
From Avigdor Luttinger: Most popular PaaS offerings (such as Longjump and the defunct Coghead) are about Situational Apps. Very few offerings (such as Force.com or our uniPaaS) are versatile and granular enough for more complex solutions, and given the current confusion levels many interested parties are not aware of the differences. 

12 Replies

| Add a Reply
  • Or, for those laymen, "what's the difference between a hosted application and a hosted application development platform?" I believe once it's restated appropriately, it sort of answers itself.

  • I don't think this is about hosted apps or dev platforms - end user development tools have always been with us it's just that recently (like a lot of things in IT) it's been given a new name. Having said that the tools are much better now and the users more tech-savvy

    A Google of the term gives some interesting results.

    Situational applications (AKA Dynamic Applications) are, according to Wikipedia, application software created for a small group of users with specific needs. The application typically has a short life span, and is often created within the group where it is used, sometimes by the users themselves. As the requirements of a small team using the application change, the application often also continues to evolve to accommodate these changes. Significant changes in requirements may lead to an abandonment of the application altogether – in some cases it is just easier to develop a new one than to evolve the one in use.

    According to IBM the term used to describe applications built to address a particular situation, problem or challenge. The development life cycle of these types of applications is quite different from the traditional IT-developed. SAs are usually built by power users using short, iterative development life cycles that are measured in days or weeks, not months or years. As the requirements change, the SA often continues to evolve to accommodate these changes. Significant changes in requirements may lead to an abandonment of the used application altogether In some cases it is simply easier to develop a new one than to update the one in use.

    One of the main, if not the most important, virtues of taking this approach is the speed at which the applications can be developed and the immediate business pay back they deliver when compared with conventional IT development and deployment cycles. The result is an improved ability to respond to or anticipate changing business demands. Also, the organization saves money whenever it changes computerized working methods – usually an expensive and protracted rigmarole. As a bonus, the organization becomes better fitted to exploit future business and computing opportunities, including business process outsourcing (BPO) and Web services.

    The downside is that the development is, more often than not, performed in isolation of the corporate needs and may run counter to corporate governance, standards and compliance issues. It therefore can be of limited value in the longer term.

  • BTW - in the spirit of full disclosure we have a product that specifically enables the development of this applications and provides and alternative to more traditional application and workflow tools. www.theprocessfactory.com

  • Thanks Jon for an excellent review. Mike Gualtiery of Forrester Research also reported on this AD segment (ref. “enlightened developers?). Clearly, this development style addresses a real need in the market. My concern is to maintain the perspective and differentiation between these and persistent (or core) applications. I have witnessed the deep frustrations of IT managers who adopted a Situational Apps tool thinking it could be used for any type of solution, and running into walls late in projects, ending up with unsatisfactory solutions both from functional and technical aspects.

    That does not mean that Situational is not good – just that one should use it for what it is meant for.

    The story (rather history) of Magic Software is quite enlightening in this respect. When Magic II was first launched in the mid-80’s, we were in the midst of the first wave of the situational buzz with data oriented application tools such as Framework, dBase, etc… Magic II innovated by offering a metadata driven environment, which was much easier to master for business professionals than code driven tools. So Magic happily promoted it to ISV’s and Enterprises, with a silver bullet message and doing away with waterfall or other development models. It worked great for a while, but as applications reached the production stage their design flaws became apparent. I recall being summoned to a large pharma enterprise by the head of their clinical tests department, because the application he proudly developed was gradually slowing down to a halt. It did not take long to discover that the data structure was so convoluted, that some lookups ended up sequentially scanning tens of thousands of records.

    The majority of the PaaS offerings today are designed for delivering Situational Applications. That is quite understandable, since on one hand the target developer audience looks for coarse grained widgets that are highly functional and simple to assemble, and for vendors it would take a significant effort and time to develop PaaS with highly granular widgets that enable the same power of implementation as coded environments. The danger though, is that the hype and buzz are so high and blinding that many prospects to not perceive the objectives and the limitations (ending up as I described above).

    So my call to action is to offer more down to earth information and transparency about what a technology is good for, so that those in need for situational tools are not overwhelmed with complexity and those looking for persistent and core solutions do not try to implement them on inappropriate foundations.

  • Our company also offers situational applications on our PaaS. They're completely customizable and fully functional without programming. Check us out at www.workxpress.com

  • Just before disappearing off to a conference last week, I posted a short video here on ebizQ discussing the different ways you can develop situational applications using Web-based tools. View it on this page: Weaving the Connected Enterprise.

    I think it's important to stress that situational applications aren't new; it's just that the Web gives us a new set of tools for building them. The Web also helps support collaborative development styles that allow developers to work closely with business users on rapid application development to meet ad hoc automation needs.

    Avigdor is right to point out that some of these tools are not built to support high performance at scale - which is why it's still important to scope out your needs from the outset, at least so that you understand whether the platform is capable of supporting what you hope to do. But I would also hope that we are getting better at engineering these platforms in a way that avoid the kind of bottlenecks he cites in his example. And I believe the notion of developing quickly to meet evolving business needs is the right way to prototype applications, even if we later have to go back and rebuild those that eventually become enduring business processes in a more carefully engineered manner.

  • At one time Situational Applications were definitely following the original definitions as described by Luba Cherbakov, Clay Sharky et al, as 'applications authored by domain expert users and communities to solve situated needs'.

    Certainly nowadays this scope of use has moved on. Practitioners have found applications MUST conform to enterprise computing scale, performance, tuning and security standards and therefore 'applications created to address new situations' simply become the first stage to forming a new component of enterprise information management.

    The primary role of situational applications remains to serve the long-tail of demand for applications requested by domain expert users that know what they need but struggle to get it in a timely manner from IT.

    At one time it was thought that users would be let lose to go build their apps as they needed them but this hasn't transpired. Simply put, users have better things to do with their time than designing applications. It's much easier for them - and for IT - for a professional analyst to trot along to a workshop and build the app in consort with the users and stakeholders using codeless software that means the app can be created in near-real-time. Once created the app can be deployed to a private cloud and the user community (whether it's one or many people) can start to use it.

    Whilst programming skills are removed from authoring apps using codeless enterprise situational applications platforms, there are still skills-sets and methods needed to make the application life-cycle work (see CAAD methods from Encanvas.

    For me, the main advantages of situational applications strategies are:
    1. IT keeps pace with user and stakeholder needs
    2. A Master Data Management model can be architected and maintained (removing the unintended impact of creating self-authored 'shadow systems' as happened with spreadsheets, then Lotus Notes and laterly Microsoft SharePoint).
    3. Faster time-to-market and better fit solutions
    4. More intuitive applications (because they're designed by domain expert users and communities who know what they want and how they want to work).
    5. More access to, and ability to re-use, existing data held in back-office systems or from third party (web) sources.
    6. Substantially less enterprise IT risk and costs through smaller IT teams and the removal of programming (no re-working, testing, tuning) and the need for browser compatibility testing etc.

  • contains a mixture of situational and non-situational information, and (ii) certain numerical ... which uses low-level lexical and syntactic features to distinguish between situational and ... However, what is necessary during a disaster event

    lenovo support

  • the situational application is "good enough" software created for a narrow group of users with a unique set of needs. The application typically (but not always) has a short lifespan, and is often created within the group where it is used, sometimes by the users themselves. here i create a website site quickbooks support in web2.o for a quickbooks support if you want to learn more in QuickBooks support then contact me inmy website

  • In computing, a situational application is "good enough" software created for a narrow group of users with a unique set of needs. The application typically (but not always) has a short life span, and is often created within the group where it is used, sometimes by the users themselves. This paper examines the non-situational (i.e., non-exophoric) pragmatic functions of the three adnominal demonstratives, óyo, wâná, and yangó in the Bantu bigpond telephone number here our support provide more information

  • What We Stand for · ACR History · What We Offer ... Russell W. Belk (1974) ,"Application and Analysis of the Behavioral Differential ... importance of various situational and non-situational influences on consumer choice, but .... the main effect of differences in responses was able to account for less than 10% of the variance. avg support for more help

  • I presented a theoretical investigation of the smartphone as a metamedium allowing the installation and launching of various applications for different purposes and uses ... Within this setting, this study specifically analyzed what non-situational contact us in Amazon Alexa customer service for theoretical

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT