Automating Business Process via MuleSoft Composer | Bangalore MuleSoft Meetup...
Putting Great KM Ideas into Practice
1. The
%tle
of
this
session
is
incredibly
broad
–
what’s
ECM?
And
what’s
a
great
KM
idea?
–
We
have
spent
many
long-‐distance
phone
calls
trying
to
agree
a
shared
understanding
for
this
presenta%on.
We
recognise
therefore
that
there
are
probably
as
many
ways
to
interpret
this
topic
as
there
are
of
you
here
today.
But
we
hope
that
there’s
enough
here
for
you
each
to
take
away
something
useful.
1
2. Speaker
Bio:
Kate
has
spent
over
10
years
designing
usable
informa%on
spaces
for
the
legal
industry.
She
ini%ally
took
her
legal
educa%on
to
one
of
the
early
pioneers
in
online
legal
publishing,
developing
deep
exper%se
in
informa%on
architecture,
content
strategy
and
the
design
of
useful,
usable
and
engaging
user
experiences.
In
2007,
Kate
started
her
own
consul%ng
prac%ce
where
she
worked
with
the
U.K.'s
leading
law
firms
to
design
and
execute
innova%ve
digital
strategies.
Now
in
Canada,
Kate
is
a
passionate
advocate
for
puRng
users
first
and
ensuring
firms
have
the
right
informa%on
architecture,
processes
and
governance
to
leverage
their
extensive
technology
investments.
2
3. Respect
to
Mark
here
for
this
quote
that
inspired
our
theme
and
we’ve
used
to
structure
our
session
this
aUernoon
3
4. That
quote
leads
us
to
ask:
how
do
we
turn
these
great
blocks
of
marble…
4
6. I
think
the
answer
may
lie
in
the
power
of
threes
(and
I
don’t
mean
your
three
panellists…)
6
7. This
is
our
ECM/KM
Triangle.
We
have
come
up
with
what
we
think
are
3
of
the
key
issues
within
the
3
points
of
this
triangle
(Data
–
Tools
–
Vision).
If
you’re
aaemp%ng
to
turn
a
great
KM
idea
into
something
tangible
then
you
need
to
make
room
for
each
of
these
during
your
project.
I
will
make
three
brief
points
about
each
of
these
components
before
handing
over
to
Karen
and
Mark
to
show
you
how
they
have
put
their
great
KM
ideas
into
prac%ce
7
8. A
word
about
triangles:
whilst
we
acknowledge
that
some
of
our
project
triangles
tend
to
force
us
to
make
compromises…
8
9. …
that
does
not
make
them
impossible
to
use
as
guides
for
project
success.
9
10. So,
first
up,
our
data.
Our
big
blocks
of
marble
siRng
unformed.
10
11. As
they
say:
if
in
doubt,
go
Dilbert.
(Here’s
one
from
September
2001
about
the
badness
of
data.
Apologies
to
those
reading
these
slides
in
handouts
but
I
only
bought
the
license
for
presenta%on
use.)
Our
data
is
locked
in
silos.
Even
if
we
know
what
we
own;
its
value
is
oUen
unknown.
Some
of
us
are
having
some
successes
using
tools
to
extract
and
analyse
this
data
(which
Mark
covers
in
his
presenta%on).
11
12. One
of
the
primary
reasons
Dilbert’s
boss
can’t
“manage”
is
because
oUen
our
data
has
no
referen%al
integrity.
It’s
amazing
what
mashups,
BI
reports,
and
new
paaerns
for
decision-‐making
can
be
formed
by
joining
data
using
unique
keys
(Client
ID,
Maaer
ID,
Document
ID,
TimeKeeper
ID)
and
that
allow
the
metadata
added
throughout
the
lifecycle
to
be
inherited,
referenced
and
used
in
new
ways.
One
firm
–
let’s
call
them
Firm
Leonardo
has
figured
this
out
early.
Each
new
KM
idea
allows
them
to
tackle
another
element
of
their
data
referen%al
integrity
process
and
clean
it
up.
Other
firms
–
let’s
call
this
one
Firm
Donatello
prefers
to
hide
their
head
in
the
sand
and
will
buy
the
next
‘silver
bullet’
technology
in
the
hope
that
something
can
auto-‐
magically
be
done
about
it
rather
than
rolling
up
one’s
sleeves
and
geRng
your
hands
dirty
with
the
data
to
join
it
up.
12
13. Is
there
a
firm
leU
on
the
planet
that
hasn’t
realised
that
the
quality
of
their
data
is
just
a
bit
rubbish?
Dear
Oscar
at
Old
Street
on
my
way
to
work
in
London
town.
Rubbish
In.
Rubbish
Out.
For
Dilbert’s
Boss
to
be
able
to
‘manage
data’
we
need
to
make
sense
of
it.
It
needs
standardizing,
normalizing,
reconciling.
It
needs
untangling.
It
needs
cleaning
and
cleansing
to
create
more
accurate,
reliable
and
useful
outputs
on
an
ECM
planorm
(such
as
we
will
show
on
SharePoint
or
Recommind).
13
14. Before
Leonardo,
portraits
of
women
were
in
profile,
showing
only
half
the
face
and
nothing
below
the
shoulders.
Here
Leonardo
turns
the
subject
almost
full
on
towards
the
viewer,
and
includes
her
hands
-‐
as
if
to
say,
"Here
she
is,
all
of
her,
fully
revealed."
But
of
course
he's
only
shown
the
parts
of
her
fit
for
public
consump%on.
The
personal
and
private
remain
hidden
behind
that
smile
and
those
eyes.
We
need
to
know
what
can
and
should
be
shared
with
others.
We
need
to
know
how
to
reassure
lawyers
that
revealing
some
informa%on
is
OK.
We
need
to
find
the
data
that
is
strictly
private
or
strictly
personal
and
lock
that
down.
We’ve
all
heard
the
stories
from
firms
about
what
can
inadvertently
get
revealed
during
some
of
these
KM/ECM
projects.
Mark
&
Karen/Suzanne
also
have
stories
to
share.
We
can
learn
from
these
stories
and
examples
and
be
prepared
to
build
in
the
%me
to
fully
analyse
and
crunch
the
data
so
we
avoid
making
the
same
mistakes.
14
15. Secondly,
our
tools.
How
we’ll
use
what
we
have
(or
buy
new
ones)
to
get
what
we
want.
15
16. As
Mark
says:
there
is
more
than
one
way
to
skin
a
cat
to
deliver
our
projects
–
but
please
not
this
one
16
17. Finally
within
the
walls
of
our
law
firms,
we
now
have
access
to
some
of
the
shiniest
technologies
around.
Huge
powerhouses
of
func%onality
and
even,
shockingly,
some
beau%fully
designed
tools
too.
Like
those
working
in
funkier
industries
have
been
using
for
years.
Some
of
these
disrup%ng
technologies
may
be,
well,
disrup%ve,
but
the
same
ques%ons
are
common
to
them
all:
-‐ What
do
our
tools
actually
do?
-‐ Let’s
do
some
feature
analysis;
how
can
we
get
what
we
want
from
our
data
using
these
tools?
-‐ How
much
configura%on
is
that
going
to
involve?
-‐ How
much
should
we
s%ck
with
OOTB?
We
know
that
it
will
simplify
any
upgrade
process
in
the
long-‐term
but
may
limit
us
to
only
thinking
within
that
“paint-‐by-‐
numbers”
box
in
the
short
term.
17
18. Enterprise
Content
Management
projects,
of
the
kinds
Karen/Suzanne
and
Mark
are
going
to
talk
about,
and
more
besides,
involve
integra%on.
To
build
our
intranets,
portals,
exper%se,
maaer
&
client
pages
and
extranets,
KM
systems,
Enterprise
Search,
content
cura%on
&
current
awareness
solu%ons,
financial
dashboards
and
so
on,
all
involve
mashing
up
our
data
and/or
integra%ng
applica%ons.
On
the
one
hand
we
have
data
integra%on
involving
ETL
tools
and
SQL
(and
therefore
indexing
that
data
as
Mark
will
describe).
While
on
the
other
we
have
applica%on
integra%on
for
SOA,
with
API
calls
to
systems
pulling
back
data
for
displaying
on
a
new
UI
(such
as
SharePoint
that
Suzanne
will
explain)
18
19. Sadly
most
of
our
tools
have
poor
user
experiences.
The
UIs
are
poorly
designed.
They
are
not
usable,
useful
or
engaging.
Whilst
‘design’
is
oUen
forgoaen
by
vendors
on
the
tools
we
buy
off
the
shelf,
we
have
the
opportunity
to
focus
on
designing
intui%ve
user
experiences
on
our
internal
projects.
Not
just
that
the
interface
‘looks
preay’
and
matches
the
corporate
colours,
but
that
it
is
task-‐oriented
for
our
lawyers
and
follows
core
user-‐centred
design
processes
(more
about
that
in
a
mo).
19
20. In
my
experience
soUware
is
just
a
small
propor%on
of
the
total
cost
of
introducing
and
running
a
system.
We
need
to
understand
what’s
really
involved
to
deliver
our
projects
on
%me,
to
budget,
and
meet
our
users’
expecta%ons.
We
also
need
to
remember
that,
as
always,
the
tools
are
our
enablers
(even
if
they
may
be
cooler
and
funkier
tools
nowadays).
It
is
what
we
do
with
those
tools
that
makes
the
difference.
20
21. And
therefore
you
need
a
vision.
You
need
to
understand
what
it
is
you
want.
21
22. And
design
maaers.
We
need
visionaries
and
visions
for
what
we
want
to
get
out
of
our
data
and
use
our
tools
for.
We
aaend
conferences
like
this
one
and
listen
to
the
visions
that
others
have
–
such
as
those
that
Karen
and
Mark
will
describe.
We
listen
to
vendors
as
they
describe
what’s
possible
with
their
tools.
We
read
inspiring
ar%cles
and
case
studies
to
let
our
imagina%ons
escape
the
box.
Allowing
us
to
see
David
within
that
block
of
marble,
or
a
Monet
on
that
blank
canvas.
Or
indeed
a
beau%ful
phone.
22
23. Apprecia%ng
and
leveraging
the
design
skills
of
your
team
is
important.
The
design
of
your
solu%on
both
architecturally
and
its
user
interface
impacts
the
success
of
your
project.
But
as
we
know,
law
firms
are
a
difficult
place
for
design
to
really
flourish;
‘design-‐by-‐
commiaee’
is
a
derogatory
term
applied
to
anything
that
has
been
poorly
designed.
This
problem
is
oUen
compounded
at
firms
where
the
commiaee
is
lacking
any
formal
design
skills
so
that
the
only
topic
that
the
team
have
any
confidence
in
expressing
is
the
colour
of
the
UI.
But
while
we’re
not
all
lucky
enough
to
have
a
Steve
Jobs
to
refer
design
decisions
to,
or
a
professional
designer
on-‐staff,
we
can
employ
good
co-‐crea%on
or
collabora%ve
design
prac%ces
by
leveraging
the
design
skills
of
our
team.
And
whilst
you’ll
s%ll
need
a
final
arbiter
or
decision-‐maker
during
the
design
process,
your
focus
should
be
on
finding
a
good
cross-‐func%onal,
mul%-‐disciplinary
team
that
share
the
vision
for
the
project
and
can
work
well
together
discussing,
researching
and
tes%ng
design
op%ons.
This
approach
will
help
avoid
many
of
the
pinalls
of
commiaee
design.
23
24. Good
IT/KM
projects
map
core
architectural
and
design
objec%ves
to
the
business’
needs
and
goals.
How
oUen
do
we
hear
“Make
it
like
Google”?
(Or
has
that
now
been
replaced
with
“Make
it
like
my
iPad”?)
But
what
does
that
actually
mean?
What
are
the
underlying
design
and
architectural
principles
that
can
turn
the
business
objec%ve
for
‘maaer
pages’
into
clear
design
principles,
such
as
making
sure
there
is
lots
of
white
space
on
the
UI?
Core
design
principles
or
‘heuris%cs’
for
designing
web
interfaces
or
search
pages
exist
on
the
Web
and
can
help
inform
your
future
decision-‐making
as
you
design,
build
and
test.
24
25. And
finally,
great
ideas
need
communica%ng!
You
need
to
communicate
your
vision
to
mul%ple
stakeholders
throughout
the
firm:
-‐ to
the
board
for
ongoing
cost
and
execu%ve
decision-‐making
-‐ to
the
technical
team
to
build
the
vision
into
something
tangible
-‐ to
end
users
for
buy-‐in
and
adop%on
Designers
and
architects
oUen
use
models
to
achieve
a
shared
vision
amongst
mul%ple
stakeholders,
such
as
this
one
made
of
Christopher
Wren’s
early
design
of
St
Paul’s.
Builders
couldn’t
read
complicated
architectural
blueprints
–
a
model
like
this
made
such
shared
communica%on
possible.
Similarly
informa%on
architects
might
draw
up
wireframes
and
other
models
to
show
the
business
what
it
is
that
will
be
built,
and
that
also
show
technical
teams
what
needs
to
be
built.
25
26. OK,
so
that’s
enough
of
pondering
the
conceptual
and
abstract,
now
onto
the
prac%cal…
26
27. And
now
here’s
Suzanne
from
Ropes
&
Gray
to
discuss
her
firm’s
great
KM
idea
that’s
been
put
into
prac%ce…
27